An IANA Registry for Level of Assurance (LoA) Profiles
draft-johansson-loa-registry-06

[Ballot comment]
A few comments about the ABNF in section 3:

  label = ( ALPHA / DIGIT )
  name = label 1*( label / "-" / "." / "_" )

First of all, I suspect the "1*" is incorrect. Are you really saying that a 1 character label is not legal, but a 2 character label is? Also, the above ABNF allows names like "A...---..." or "1____". Is that really what you want? Suggest:

  name = label *( [ "-" / "." / "_"] label)

That's one or more ALPHA or DIGIT, optionally separated by a single hyphen, period, or underscore. I'm not sure that's what you want, but it seems more sane than the what you've got.

  reserved = loa / al / num
  loa = ( "l" / "L" ) ( "o" / "O" ) ( "a" / "A") *DIGIT
  al = ( "a" / "A") ( "l" / "L") *DIGIT
  num = *DIGIT

This can be tremendously simplified. Remember that in ABNF, any string enclosed in double quotes is by definition case insensitive, so your alternate uppercase and lowercase is redundant. Furthermore, what you are really saying is "Either 'LOA' or 'AL' (upper, lower, or mixed case) followed by digits, or just digits". The following covers all cases:

reserved = [ "LOA" / "AL" ] *DIGIT

[Ballot comment]
Update: I'm happy with the changes in -05.  I particular like the new version of Section 4.1.  And I'm happy with Informational, given the recent changes.

[Ballot discuss]
Section 5 is confusing (it has drawn comments from several reviewers). Can it be reworded to avoid the confusion that's been expressed? Registries are often used to help implementations/deployments accidentally use the same name for two different purposes. The description here does not seem to consider that part of the motivation for having a registry - in fact, it goes to some length to tell users to expect there to be names in use that aren't listed, and by inference, might collide. Discussing the implications of such a collision may help avoid them.

[Ballot comment]
I agree with the comments posted about the second paragraph of section 5. If it needs to stay (even in a rewritten form), please consider providing an example of the kind of implied meaning that a user of the registry must not assume.

[Ballot discuss]
I agree with Pete's DISCUSSion and am also not a fan of 2119 keywords being used in this document.

I would like to better understand if the concept of a LoA is consistent across the types of frameworks mentioned in this document.  The introduction says that the registry will support LoAs from a variety of frameworks. However, the description of the Context Class in Section 3 talks about XML Schemas compliant with SAML 2.0.  Is this registry limited to frameworks compliant with SAML 2.0?  If so, this needs to be specified.

[Ballot comment]
I am not sure why the second paragraph in the Introduction begins and ends with underscores.

Are there any existing LoAs that should be pre-populated in this table?  If so, they should be shown in section 6.

[Ballot discuss]

  The Gen-ART Review by David Black on 1-Apr-2012 lead to some
  discussion and agreement on some document updates.  The updates
  have not appeared yet.  The review can be found here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07309.html

[Ballot comment]
I agree with Pete's DISCUSS, as it refers to Section 5.  I see no problem with using an Informational document to do what Section 4 does -- IANA will set up the registry as stated, and the terms specified here aren't meant to be used beyond this document, so Informational is fine.  But Section 5 is telling implementors of *something* what they MUST and MUST NOT do, and Informational doesn't seem right for that.

The second paragraph of Section 5 leaves me shaking my head.  I'd like to see it be more clear about what one MUST NOT infer.  It strikes me as a really wishy-washy statement as it is.

Section 7 is missing something after "An implementor of".  (I'd also hyphenate "level-of-assurance URIs", to make it clear that it's a compound modifier.)

And I agree with Stephen's comment that the definition of "URI" in Section 3 should say something, one way or another, about what expectations do or don't exist on the lifetime of the URI.  Also, is it acceptable/expected/to-be-avoided to have multiple URIs registered that define the same LoA profile?  Given that the URI is the registry key, it seems important to expand a bit on this stuff here.

[Ballot comment]

What is the expectation for stability of the URI and URL
elements of a registration? Should an expert disallow e.g.
bit.ly or a blog URL? I think it'd be good to say something
here. I don't care what you choose for any of the
reasonable choices:-)

[Ballot discuss]
[I don't feel very strongly about this, so if everyone else is OK with it, I am happy to clear this DISCUSS. But I did think it was worthy of DISCUSSion.]

If this was simply the creation of a registry, I wouldn't have thought twice about its status as Informational. But section 4 is giving a particular process and policy for additions to the registry and section 5 is attributing semantics for protocol users (both of them using 2119 language just to make the point). Doesn't that mean this should be a BCP since it's defining IETF policy and procedure?

[Ballot comment]
I am not a fan of using 2119 language in the registration template. You are not giving instructions to implementers on interoperability or damage to the network; this is for registrants and IANA. And in all cases I can find, it is simply unnecessary. I suggest:

OLD:

  The following information MUST be provided with each registration:

NEW:

  The following information must be provided with each registration:

OLD:

  Informational URL:  A URL containing auxilliary information.  This
      URL MUST minimally reference contact information for the
      administrative authority of the level of assurance definition.

NEW:

  Informational URL:  A URL containing auxilliary information.  At a
      minimum this URL needs to reference contact information for the
      administrative authority of the level of assurance definition.

OLD:

  Note that it is not uncommon for a single XML Schema to contain
  definitions of multiple URIs.  In that case the registration MUST be
  repeated for each URI.  Both the name and the URI MUST uniquely
  identify the LoA.

NEW:

  Note that it is not uncommon for a single XML Schema to contain
  definitions of multiple URIs.  In that case a separate registration is
  to be used for each URI.  The name and the URI are to uniquely
  identify the LoA.

OLD:

  The name MUST fulfill the following ABNF:

NEW:

  Names are defined by the following ABNF:

OLD:

  The following ABNF productions represent reserved values and names
  matching any of these productions MUST NOT be present in any
  registration:

NEW:

  Names that correspond to the following ABNF productions are reserved
  values and are not to be registered:

[Ballot discuss]
Quick to fix this one...

Section 4.

  The initial pool of expert and the
  review criteria are outlined below.
     
The pool of expertise isnot listedin this document. Suggest you simply
strike that text.

[Ballot comment]
Would be nice if SAML was expanded somewhere early in the document.

---

Please include a reference to the document that defines the ABNF you
are using.

IANA understands that, upon approval of this document, there is a single
IANA action that IANA must complete.

Upon approval of this document a new registry, called the "SAML Level of
Assurance (LoA) Context Class Registry" will be created.

Each new entry in this registry will contain the following:

URI
Context Class
Name
Informational URL

The registry is to be managed using the "Designated Expert Review"
policy from RFC5226. Upon approval and publication of the document, the
IESG will be requested to nominate Experts for this registry.

IANA understands that there are no initial registrations in this registry.

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

Reply-To: ietf@ietf.org

Subject: Last Call:  (An IANA registry for Level of Assurance (LoA) Profiles) to Informational RFC





The IESG has received a request from an individual submitter to consider

the following document:

- 'An IANA registry for Level of Assurance (LoA) Profiles'

  as an Informational RFC



The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailing lists by 2012-04-03. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





  This document establishes an IANA registry for Level of Assurance

  (LoA) Profiles.  The registry is intended to be used as an aid to

  discovering such LoA definitions in protocols that use an LoA

  concept, including SAML 2.0 and OpenID Connect.









The file can be obtained via

http://datatracker.ietf.org/doc/draft-johansson-loa-registry/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-johansson-loa-registry/ballot/





No IPR declarations have been submitted directly on this I-D.

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the document
        and, in particular, does he or she believe this version is ready
        for forwarding to the IESG for publication?

Tim Polk

  (1.b) Has the document had adequate review both from key members of
        the interested community and others? Does the Document Shepherd
        have any concerns about the depth or breadth of the reviews that
        have been performed?

The document has been socialized and reviewed by members of the identity
community specifically the Kantara Identity Assurance WG and the Kantara
Federation Interoperability WG. Members of these WGs have in turn solicited
comments outside the Kantara community. Members of the Kantara WGs include
active participants in the IETF and the OASIS SSTC.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective, e.g.,
        security, operational complexity, someone familiar with AAA,
        internationalization or XML?

Nothing that can't be handled in an IETF-wide last call.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he or
        she is uncomfortable with certain parts of the document, or has
        concerns whether there really is a need for it. In any event, if
        the interested community has discussed those issues and has
        indicated that it still wishes to advance the document, detail
        those concerns here.

No

  (1.e) How solid is the consensus of the interested community behind
        this document? Does it represent the strong concurrence of a few
        individuals, with others being silent, or does the interested
        community as a whole understand and agree with it?

The document has seen review and comments by a set of core participants
in the identity community.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in

        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
        enough; this check needs to be thorough. Has the document met all
        formal review criteria it needs to, such as the MIB Doctor, media
        type and URI type reviews?

Yes

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that are
        not ready for advancement or are otherwise in an unclear state?
        If such normative references exist, what is the strategy for their
        completion? Are there normative references that are downward
        references, as described in [RFC3967]? If so, list these downward
        references to support the Area Director in the Last Call procedure
        for them [RFC3967].

There are 2 normative references. One is 2119 and the other is an OASIS
specification which is currently in CS (comitte specification) ie the final
stage of completion. No changes are expected.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body of
        the document? If the document specifies protocol extensions, are
        reservations requested in appropriate IANA registries? Are the
        IANA registries clearly identified? If the document creates a new
        registry, does it define the proposed initial contents of the
        registry and an allocation procedure for future registrations?
        Does it suggested a reasonable name for the new registry? See
        [I-D.narten-iana-considerations-rfc2434bis]. If the document
        describes an Expert Review process has Shepherd conferred with the
        Responsible Area Director so that the IESG can appoint the needed
        Expert during the IESG Evaluation?

The document is setup for an IANA registry. No initial content exists. An
initial pool of revievers is proposed as:

* TBD

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML code,
        BNF rules, MIB definitions, etc., validate correctly in an
        automated checker?

Yes

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Writeup? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary

The notion of a "Level of Assurance" (LoA for short) is a common way to
express "strength" or "quality" of a digital identiy. Federations and trust
frameworks define such LoAs by establishing conditions on identity proofing,
credentials management and authentication strength. Protocols that carry
identity information (eg ABFAB, SAML or OpenID Connect) reference LoAs to
express the quality of an identity claim or assertion.

This document establishes an IANA registry for Level of Assurance Profiles. The
registry is intended to be used as an aid to discovering such LoA definitions in
protocols that use an LoA concept, including SAML 2.0 and OpenID Connect.

    Working Group Summary

This work has been done as an individual contribution and is not part of any
IETF WG. The work has been socialized in and reviewed by the identity community
where identity assurance is discussed, including the Kantara Identity Assurance
WG and the Kantara Federation Interoperability WG and the OpenID Connect
community.

    Document Quality   

There is a concrete demand for the registry from vendors that implement
identity protocols aswell as from organizations that implement trust
frameworks.