<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <font size="+1"><tt>HI Tim<br>
        <br>
        I will contact you off list and hope we can review this
        together. I will put my full idea to you and see what you think
        of the whole plan. In the mean time I have added a few comments
        below.<br>
        <br>
        cheers<br>
        denis<br>
      </tt></font><br>
    <div class="moz-cite-prefix">On 16/05/2015 16:46, Tim Bruijnzeels
      wrote:<br>
    </div>
    <blockquote cite="mid:55C9789E-14DE-4B9C-BAE1-74F1E9A377F8@ripe.net"
      type="cite">
      <meta http-equiv="Context-Type" content="text/html;
        charset=windows-1252">
      Hi Denis and all,
      <div class=""><br class="">
      </div>
      <div class="">
        <div>
          <blockquote type="cite" class="">
            <div class="">On 15 May 2015, at 18:34, denis <<a
                moz-do-not-send="true"
                href="mailto:ripedenis@yahoo.co.uk" class="">ripedenis@yahoo.co.uk</a>>
              wrote:</div>
            <br class="Apple-interchange-newline">
            <div class="">
              <div class=""> <tt class="">Hi Tim and All<br class="">
                  <br class="">
                  Personalised authorisation is an idea I developed over
                  the last few years. I talked to many people in the
                  community about it at various RIPE meetings and
                  started to build up support for my ideas. </tt></div>
            </div>
          </blockquote>
          <div><br class="">
          </div>
          <div>
            <div class="">I believe that the WG appreciates your efforts
              on this, and remembers your presentation at RIPE 68:</div>
            <div class=""><a moz-do-not-send="true"
href="https://ripe68.ripe.net/presentations/299-DB_WG_personalised_Auth_RIPE_68.pdf"
                class="">https://ripe68.ripe.net/presentations/299-DB_WG_personalised_Auth_RIPE_68.pdf</a></div>
            <div class=""><br class="">
            </div>
          </div>
          <br class="">
          <blockquote type="cite" class="">
            <div class="">
              <div class=""><tt class="">The basic idea was to allow
                  authorisation tokens in PERSON objects,</tt></div>
            </div>
          </blockquote>
          <div><br class="">
          </div>
          <div>Yes, the important point here is that the credentials are
            on PERSONs, rather than in one anonymous blob that is
            today's MNTNER.</div>
        </div>
      </div>
    </blockquote>
    <br>
    Agreed, but in your proposal you are missing several key points
    about how these credentials can be used. I agree on having the
    option for PERSON objects to be self maintaining, but disagree that
    you should not allow an organisation to manage the collection of
    PERSON objects. There are many reasons why an organisation does
    this. They may want to not allow anyone to use a password and
    require all staff to use SSO, for example. By maintaining all the
    PERSON objects they are in control of that. They may want to be able
    to delete the PERSON object when the person leaves the company. They
    may want notifications to be centralised. The PERSON objects may
    only contain corporate information instead of actual personal data
    to reflect the persons corporate identity.<br>
    <br>
    There was also a major oversight in the original implementation of
    RPSL. Allowing PERSON object to be directly referenced anywhere has
    caused so many problems to so many organisation over the last 15
    years and continues to do so today. Here is an opportunity to start
    fixing that as we move forward. By only allowing PERSON objects with
    "auth:" to be referenced in a ROLE object and then using the ROLE as
    the maintaining object, not only do we make it more intuitive, but
    we decouple the direct references to PERSON objects throughout the
    rest of the database. As time goes on that will prove to be a
    massive plus.<br>
    <br>
    <blockquote cite="mid:55C9789E-14DE-4B9C-BAE1-74F1E9A377F8@ripe.net"
      type="cite">
      <div class="">
        <div><br class="">
          <blockquote type="cite" class="">
            <div class="">
              <div class=""><tt class=""> group these into ROLE objects
                  and use the ROLE 'instead of' a MNTNER. This is much
                  more intuitive and better reflects real life business
                  operations. The MNTNER object is an abstract construct
                  that many people simply don't understand. The long
                  term goal was to (possibly) eventually deprecate
                  MNTNER objects.</tt></div>
            </div>
          </blockquote>
          <div><br class="">
          </div>
          <div>
            <div class="">There are different opinions on how to refer
              to authorised persons.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    You said it yourself that the first 3 hours of a DB training course
    are spent explaining how to create a PERSON and MNTNER object. That
    tells a story. If you ask someone who maintains their data they say
    "I do" or "We do". "I" is a PERSON object. "We" is a ROLE object.
    This is how people naturally think. Many people simply don't
    understand what a MNTNER is. It is not even a pronounceable word to
    a native English speaker. It is abstract and non intuitive. I agree
    technically there is no difference between using a MNTNER or ROLE
    object to maintain data. It is just semantics. But there is a world
    of difference in perception and intuitiveness. The concept of a
    group of people maintaining data naturally fits a role. I accept we
    could achieve the same result if we simply renamed the MNTNER as
    something like AUTH-ROLE and it becomes a special case of a ROLE
    object. But long term I still favour combining both MNTNER and IRT
    with ROLE and make this one of the most powerful objects used to
    manage your data in the DB. (Then people will start to understand
    why "abuse-c:" was implemented the way it is.)<br>
    <br>
    <blockquote cite="mid:55C9789E-14DE-4B9C-BAE1-74F1E9A377F8@ripe.net"
      type="cite">
      <div class="">
        <div>
          <div>
            <div class=""><br class="">
            </div>
            <div class="">The idea to use ROLEs instead of MNTNERs was
              presented again at RIPE 69, along side with the idea of
              just allowing to refer to PERSONs from MNTNERs:�<a
                moz-do-not-send="true"
href="https://ripe69.ripe.net/presentations/125-ripe69-db-wg-pers-auth.pdf"
                class="">https://ripe69.ripe.net/presentations/125-ripe69-db-wg-pers-auth.pdf</a></div>
            <div class=""><br class="">
            </div>
            <div class="">There was no support from the room, nor in
              informal discussions with working group members, for the
              option of using ROLEs instead of MNTNERs. While the basic
              idea sounds attractive there are a lot of problems on
              closer inspection. MNTNER objects differ from ROLEs in a
              number of ways that make this, and the ultimate
              deprecation of MNTNERs difficult. Slides 13 lists what is
              missing from ROLEs, and would be needed to use them in an
              mnt-* context. Slide 14 lists what is missing from MNTNERs
              that would have to be made up, or made optional possibly
              with business rules enforcing behaviour (e.g. address may
              still be needed for a *-c referenced role), if remaining
              MNTNERs were to be converted into ROLEs. And if the latter
              isn't done, then we would have to live with mnt-* being
              allowed to refer to either a MNTNER or a ROLE (with
              special attributes turned on), for a long time, and this
              is hardly intuitive.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    I think you need to present a full plan rather that just suggest
    partial ideas. Just asking if we should replace MNTNER with ROLE
    does not in itself sound like an inspiring move. My proposal to
    allow this in a parallel track means you can either use the simpler,
    intuitive method, or stick with the old MNTNER method. I think once
    people realise the benefits they would move over.<br>
    <br>
    <blockquote cite="mid:55C9789E-14DE-4B9C-BAE1-74F1E9A377F8@ripe.net"
      type="cite">
      <div class="">
        <div>
          <div>
            <div class=""><br class="">
            </div>
            <div class="">There was however support for the basic
              concept of extending MNTNERs with personalised
              organisation in a backward compatible way that requires no
              action from any of the over 50,000 maintainers in the
              database. The RIPE NCC was tasked with working out and
              presenting a new plan based on this resulting in the
              presentation given at RIPE70:�<a moz-do-not-send="true"
                href="https://ripe70.ripe.net/presentations/165-ripe70-pers-auth.pdf"
                class="">https://ripe70.ripe.net/presentations/165-ripe70-pers-auth.pdf</a></div>
            <div class=""><br class="">
            </div>
          </div>
          <br class="">
          <blockquote type="cite" class="">
            <div class="">
              <div class=""><tt class=""> Trying to feed personalised
                  auth into objects via MNTNERs, even worse through
                  ROLEs and MNTNERs, is not only adding extra,
                  unnecessary, layers of abstraction but making it even
                  less intuitive and totally unrelated to real life
                  situations.<br class="">
                </tt></div>
            </div>
          </blockquote>
          <div><br class="">
          </div>
          <div>
            <div class="">
              <div class="">In this proposal MNTNER objects remain the
                specialised security objects that they are today,
                including features lacking from the normal
                contact-oriented ROLE object, but personalised
                authorisation is added with minimal changes to the
                schema to allow those users that want to make use of
                this to do so, without forcing any existing maintainer
                to be modified.</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    My proposal also allows anyone to continue to do what they do now
    and ignore all the changes.<br>
    <br>
    <blockquote cite="mid:55C9789E-14DE-4B9C-BAE1-74F1E9A377F8@ripe.net"
      type="cite">
      <div class="">
        <div>
          <div>
            <div class="">
              <div class=""><br class="">
              </div>
              <div class="">This is low hanging fruit.</div>
              <div class=""><br class="">
              </div>
            </div>
            <div class="">Referring from an object to a MNTNER, and from
              that MNTNER to a number of authorised PERSONs does not add
              any layers compared to using a ROLE there instead of the
              MNTNER. And note that I did not favour using ROLEs in
              between MNTNERs and authorised PERSONs for this very
              reason, in response to your comment through chat during
              the WG session that this should be allowed.</div>
          </div>
          <br class="">
          <blockquote type="cite" class="">
            <div class="">
              <div class=""><tt class=""> <br class="">
                  My original idea was to simplify the auth model and
                  bring it closer to reality, adding extra, beneficial
                  features, without losing any of the operational
                  features currently available through MNTNERs....but
                  without the need to use MNTNERs. Everything can be
                  done with PERSON and ROLE objects...which people
                  understand.<br class="">
                </tt></div>
            </div>
          </blockquote>
          <div><br class="">
          </div>
          <div>
            <div class="">I honestly believe that the now proposed model
              does all this, the one thing people need to understand is
              that a MNTNER despite the name 'maintainer' being singular
              would be allowed to make explicit references to different
              PERSONs who do the actual maintaining.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <blockquote cite="mid:55C9789E-14DE-4B9C-BAE1-74F1E9A377F8@ripe.net"
      type="cite">
      <div class="">
        <div>
          <div>
            <div class=""><br class="">
            </div>
            <div class="">
              <div class="">The MNTNER is like a ROLE for security
                context.</div>
            </div>
            <div class=""><br class="">
            </div>
            <div class="">The MNTNER has extra things important to
              security like:</div>
            <div class="">�- where do the alerts go?</div>
            <div class="">�- where do the notifications go?</div>
            <div class=""><br class="">
            </div>
            <div class="">And it's lacking other things relevant to
              people looking to contact a group of people, but
              irrelevant when authorising a group of people. Such as:
              address, email, phone and fax.</div>
          </div>
          <div><br class="">
          </div>
          <br class="">
          <blockquote type="cite" class="">
            <div class="">
              <div class=""><tt class=""> I had this all worked out in
                  my head how to achieve all this, which is not
                  technically very difficult to implement and not hard
                  to understand and can be done in parallel with current
                  MNTNER operation (so no one has to change if they
                  don't want to). But I never wrote any of this down or
                  presented any detail to anyone. So I would like to
                  present an alternative option to the community, along
                  the lines I was thinking and had discussed briefly
                  with many people. It may take me a week or so to write
                  it all out and present it as a RIPE Labs article.<br
                    class="">
                  <br class="">
                  cheers<br class="">
                  Denis Walker<br class="">
                  Independent Netizen<br class="">
                </tt><br class="">
                <div class="moz-cite-prefix">On 15/05/2015 10:27, Tim
                  Bruijnzeels wrote:<br class="">
                </div>
                <blockquote
                  cite="mid:66A34212-F666-4C9A-8C3E-546032855D7A@ripe.net"
                  type="cite" class=""> Dear working group,
                  <div class=""><br class="">
                  </div>
                  <div class="">Yesterday during the WG session we
                    presented a proposal for implementing personalised
                    authorisation:</div>
                  <div class=""><a moz-do-not-send="true"
href="https://ripe70.ripe.net/wp-content/uploads/presentations/165-ripe70-pers-auth.pdf"
                      class="">https://ripe70.ripe.net/wp-content/uploads/presentations/165-ripe70-pers-auth.pdf</a></div>
                  <div class=""><a moz-do-not-send="true"
                      href="https://ripe70.ripe.net/archives/video/123"
                      class="">https://ripe70.ripe.net/archives/video/123</a></div>
                  <div class=""><br class="">
                  </div>
                  <div class="">As recorded in the first cut of the
                    minutes:</div>
                  <blockquote type="cite" class="">
                    <div class="">
                      <div class="">D. Personalised authentication (Tim
                        Bruijnzeels, RIPE NCC)</div>
                      <div class="">� (See presentation)</div>
                      <div class="">� This will allow one click creation
                        of person objects</div>
                      <div class="">� Maintain credentials in one place.</div>
                      <div class="">� Allow better auditing.</div>
                      <div class="">� Done by extending person object to
                        have multiple optional auth: attribute</div>
                      <div class="">� This will ultimately allow
                        existing auth: sso references to be cleaned up</div>
                      <div class="">� Last auth: attribute should not be
                        removed from a person object that is used in an
                        authorisation context.</div>
                    </div>
                  </blockquote>
                  <div class=""><br class="">
                  </div>
                  <div class="">Apart from questions about possible
                    additions below, there seemed to be general approval
                    for the above as an addition to the existing
                    maintainer mechanism.</div>
                  <div class=""><br class="">
                  </div>
                  <div class="">We would very much like to implement
                    this soon. We are already working on improving the
                    way users can log in and use the web updates, and
                    manage maintainers (and who is authorised for them),
                    so having this would be extremely useful for that
                    effort.</div>
                  <div class=""><br class="">
                  </div>
                  <div class="">Technically I don't think the above has
                    to depend on further extensions below. Roles can be
                    added at any time that we consensus on them, and
                    showing audit logs is a separate effort - building
                    on this.</div>
                  <br class="">
                  <blockquote type="cite" class="">
                    <div class="">
                      <div class="">� Should this be extended to the
                        role object as well? This would involve
                        additional business rules but is technically
                        possible.</div>
                    </div>
                  </blockquote>
                  <div class=""><br class="">
                  </div>
                  <div class="">
                    <div class="">I understand and fully agree that
                      there is a need to maintain a list of authorised
                      persons centrally. But in effect a maintainer can
                      be used for this purpose. Multiple objects can be
                      maintained by the same maintainer, and the list of
                      persons authorised can then be managed on this
                      single maintainer:</div>
                    <div class=""><br class="">
                    </div>
                    <div class="">obj1 � �---\</div>
                    <div class="">� � � � � � ---> mnt1 �--->
                      �pers1</div>
                    <div class="">obj2 � �---/ � � � � � \--> �pers2</div>
                    <div class="">�</div>
                    <div class=""><br class="">
                    </div>
                    <div class="">In other words, just like role objects
                      can group persons in a 'contact' context,
                      'maintainers' could group persons in a
                      'authorisation' context, where also other things
                      such as "upd-to:" etc can find a home.</div>
                    <div class=""><br class="">
                    </div>
                    <div class="">So, technically I don't think there is
                      a need to have another role object here:</div>
                    <div class=""><br class="">
                    </div>
                    <div class="">
                      <div class="">obj1 � �---\</div>
                      <div class="">� � � � � � ---> mnt1 �--->
                        �role1 �---> pers1</div>
                      <div class="">obj2 � �---/ � � � � � � � � � � �
                        �\--> pers2</div>
                    </div>
                    <div class=""><br class="">
                    </div>
                    <div class="">Conceptually this can work of course,
                      but it adds some complexity, and things to
                      resolve:</div>
                    <div class=""><br class="">
                    </div>
                    <div class="">a) referencing roles from maintainers,
                      and authorised persons from roles</div>
                    <div class=""><br class="">
                    </div>
                    <div class="">The proposal was to refer to
                      authorised persons from maintainers like this: �
                      auth: �person-<nichandle></div>
                    <div class=""><br class="">
                    </div>
                    <div class="">Can we resolve this by allowing:</div>
                    <div class="">� = auth: �role-<nichdl> on
                      maintainers</div>
                    <div class="">� = auth: �person-<nichdl> on
                      roles�</div>
                    <div class=""><br class="">
                    </div>
                    <div class="">But no other auth: flavours for now.</div>
                    <div class=""><br class="">
                    </div>
                    <div class="">Also note that this person is not
                      necessarily an authorisation *contact* for others.
                      If we follow current practice consistently we
                      would filter this value for security purpose.</div>
                    <div class=""><br class="">
                    </div>
                    <div class="">b) business rules regarding
                      auth->role</div>
                    <div class=""><br class="">
                    </div>
                    <div class="">Suggestion:</div>
                    <div class="">- A role can only be added to a
                      maintainer as "auth: role-<nichdl>" if it
                      has at least one "auth: person-<nichdl>"</div>
                    <div class="">- The last "auth: person" can not be
                      removed from a role if it's referenced anywhere as
                      "auth: role-"</div>
                    <div class="">
                      <div class="">- As before: "auth:
                        person-<nichl>" can only be added if the
                        person has at least one "auth:
                        <something>"</div>
                      <div class="">- As before: the last "auth:" can
                        not be removed from a person if it's referenced
                        anywhere as "auth: person-"</div>
                    </div>
                  </div>
                  <div class=""><br class="">
                  </div>
                  <blockquote type="cite" class="">
                    <div class="">
                      <div class="">� It would be useful to record what
                        credential (maintainer) was used to make a
                        particular change to an object and this change</div>
                      <div class="">� would facilitate this. RV was
                        asked to raise this on the mailing list.</div>
                    </div>
                  </blockquote>
                  <div class=""><br class="">
                  </div>
                  <div class="">Currently we do know internally which
                    maintainer was used to submit a successful update,
                    but not which credential. Technically this could be
                    added of course. And in case of SSO or PGP people
                    can get some idea of which user did the update. But
                    showing which password hash was used for an update
                    may not be best security practice.</div>
                  <div class=""><br class="">
                  </div>
                  <div class="">With authorisation delegated to persons
                    (possibly through roles) we will be able to give a
                    much more better output. We can refer to the name of
                    the person, rather than a credential that should be
                    private to that person.</div>
                  <div class=""><br class="">
                  </div>
                  <div class="">Also note that for any of this we will
                    also need to be sure that the user viewing this
                    information is authorised to see this. So what we
                    had in mind here is to show this only on the web
                    interface for logged in users authorised for at
                    least one mnt-by of the object they are looking at.</div>
                  <div class=""><br class="">
                  </div>
                  <div class=""><br class="">
                  </div>
                  <div class=""><br class="">
                  </div>
                  <div class=""><br class="">
                  </div>
                  <div class=""><br class="">
                  </div>
                  <div class=""><br class="">
                  </div>
                  <div class=""><br class="">
                  </div>
                  <div class=""><br class="">
                  </div>
                  <div class=""><br class="">
                  </div>
                  <div class=""><br class="">
                  </div>
                </blockquote>
                <br class="">
              </div>
            </div>
          </blockquote>
        </div>
        <br class="">
      </div>
    </blockquote>
    <br>
  </body>
</html>