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

[Ted Hardie <[e-mail]>]

On Sun, Apr 8, 2012 at 5:21 AM, Leif Johansson <[e-mail]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
>> 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?
>

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.


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

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.


>> 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:[e-mail]  be
>> acceptable?
>>
>
> Ah yes. Good catch!
>

Just to confirm, you plan to add a list?


>>
>> Minor Issues:
>>
>> The example given in 3.1 does not give an information URL, but the
>> registration template implies that this field is mandatory.
>>
>
> Good catch. Quite embarrassing :-)
>
>> 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.
>>
>
> 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.
>>
>>
>> In the Acknowledgements Section:
>>
>> The various versions of the draft was socialized
>>
>> should be "were socialized".
>
> Yep
>

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