Subject: [apps-discuss] Reivew of draft-johansson-loa-registry

From: Ted Hardie <[email-masked]>
Date: Fri, 6 Apr 2012 11:59:53 -0700

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:[email-masked]  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".

---

From: Leif Johansson <[email-masked]>
Date: Sun, 08 Apr 2012 14:21:43 +0200

On 04/06/2012 08:59 PM, Ted Hardie wrote:
> I have been selected as the Applications Area Directorate reviewer
> for this draft (for background on appsdir, please see 
>  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.

Excellent review Ted, thank you very much!

> 
> 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:
> 
> SAML Authentication Context Profiles, but with the understanding
> that other protocols may re-use the registry contents  in their own
> contexts:
> 
> 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.

No that would not be consistent with the intent of the registry. Did you
suggest that such a practice would be useful?

> 
> 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.
> 

I see your point. However I believe there is value in having very
clear guidance which the ABNF does give... Perhaps if I include
text in the reviewers guide along the lines of "The reviewers should
exclude registrations where the short name does not unambiguously
identify the LoA definition or where the short name is a simple
variation on one of the reserved (cf above) LoA names."

> schemes might be useful, as it is not clear whether a contact-only
> URI would be acceptable. The document says:
> 

Ah yes. Good catch!

> registration template implies that this field is mandatory.
> 

Good catch. Quite embarrassing :-)

> 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.
> 

I like it.

> 
> 
> 
> 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.
> 
> 

Yep

	Cheers Leif

---

From: Ted Hardie <[email-masked]>
Date: Mon, 9 Apr 2012 07:42:07 -0700

On Sun, Apr 8, 2012 at 5:21 AM, Leif Johansson <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>

Honestly, I have no opinion on whether having multiple registrations
with different
informational URLs would be useful or not; it's hard to say without knowing how
much re-use there would be.  I think it would be best if you clarified that each
registration must present a unique URI, though, if you don't intend
for that to happen.

> variation on one of the reserved (cf above) LoA names."

That would make sense.  Once you have updated the document and
added the ABNF reference, a fresh run through an ABNF checker is
probably in order.

>> Would an informational URL of mailto:[email-masked]  be

Just to confirm, you plan to add a list?

>> should be "were socialized".

Thanks for your quick reply,

regards,

Ted Hardie

>        Cheers Leif
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk+BgtEACgkQ8Jx8FtbMZnfR4ACbBK2JHXFpM9nEehqAp6IinGW9
> 2HwAn3qHKIXXpVHEHEEJ7+6qpmIZTc+a
> =mHA3
> -----END PGP SIGNATURE-----

---

From: Leif Johansson <[email-masked]>
Date: Wed, 11 Apr 2012 21:14:39 +0200

>>>> Would an informational URL of
>>>> mailto:[email-masked]  be acceptable?
>>>> 
> 
> Ah yes. Good catch!
> 
> 

yep