I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:  draft-johansson-loa-registry
Reviewer:Ted Hardie
Review Date: April 6, 2012

Summary:

There are some clarifications needed to ensure that the resulting registry
is as useful as possible.

Major Issues:

The document currently describes a registry primarily focused on
SAML Authentication Context Profiles, but with the understanding that other
protocols may re-use the registry contents  in their own contexts:

   Although the registry will contain URIs that reference SAML
   Authentication Context Profiles other protocols MAY use such URIs to
   represent levels of assurance definitions without relying on their
   SAML XML definitions.  Use of the registry by protocols other than
   SAML or OpenID Connect is encouraged.

Each registration contains a URI, a schema definition, a short name, and an
informational URL.  It is not clear, however, whether these URIs must be
unique across registrations.  Would it be possible, for example, to have a
non-SAML usage documented in this registry by having it re-register with an
existing URI, but a different informational URL? I believe this point should be
made explicit as guidance to the expert reviewers.

The document uses ABNF to describe the required format of the short name,
but there is no reference for ABNF given; presumably RFC5234 should be
included as a reference.   The ABNF  in the document  excludes
specific prefixes (LOA, AL)
in order to avoid non-descriptive short names, but it is not clear why it also
excludes all-digit references.  In general, the use of the ABNF for this seems
fairly clumsy, and I would suggest that the document shift this from
ABNF determinism
to advice  (to both registrants and expert reviewers), to help ensure
that the resulting names
are useful. There are a host of equally problematic possibilities
(saml-loa-10, for example)
that good guidance would better avoid than ABNF rules.

For the "informational URL" definition, a list of permitted URI
schemes might be useful,
as it is not clear whether a contact-only URI would be acceptable.
The document says:

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

Would an informational URL of mailto:loa-registrant@example.org  be acceptable?


Minor Issues:

The example given in 3.1 does not give an information URL, but the
registration template
implies that this field is mandatory.

In 4.1, the document twice uses the term "bona fide" to describe entries:

  The expectation of the IANA LoA Registry is that it contain bona fide
   Level of Assurance Profiles while not presenting a very high bar for
   entry.  Expert reviewers SHOULD NOT place undue value in any
   percieved or actual quality of the associated trust framework or
   federation and SHOULD only exclude such registrations that in the
   view of the experts do not represent bona fide attempts at defining
   an LoA.

I suggest that "good faith" be used to replace at least one of these,
to clarify the meaning.




Nits: [list editorial issues such as typographical errors, preferably
by section number]

I personally found the Introduction somewhat hard to parse, and I believe
it would be improved by bringing paragraphs two and three forward,
then following them
with the gist of paragraphs one and four.


In the Acknowledgements Section:

The various versions of the draft was socialized

should be "were socialized".