OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [security-services] Final text for NameIndentifier (includes fixesfrom March 5 Con-C all)



Thanks Prateek, almost there, just a couple more nits ...

I agree with Eve about removing the "MUST" from the format descriptions, 
in favor of just "is".

> #emailAddress:
>  
>        Indicates that the value of the Name element MUST be an email
> address.
>        The format of an email address is an "addr-spec" as defined in RFC
> 2822 [RFC 2822]. 
>        An addr-spec has the form "local-part@domain". Note that an addr-spec
>        has no phrase (such as a common name) before it, has no comment (text
>        surrounded in parentheses) after it, and is not surrounded by "<" and
>        ">". 

I'm fine with calling it an "emailAddress", but we have to be clear that
it is just in the *form* of an email address.  The Internet2 "eduPerson"  
schema also promotes this format for security identifiers
("eduPersonPrincipalName"), and there was remarkable confusion among
readers of the document about whether the spec intended that these had to
be real working email addresses, which (I strongly assert) they do not,
either in eduPerson or here.  So I suggest:

  Indicates that the value of the Name element is in the form of an 
  Internet email address, specifically the "addr-spec" form defined in 
  section 3.4.1 of RFC 2822 [RFC 2822].  An addr-spec has the form ...

> ...
> The interpretation of the name qualifier and the name are left to
> individual implementations, including issues of anonymity, pseudonymity,
> and the persistence of the identifier with respect to the asserting and
> relying parties.

I'll re-spin Scott's spin on this to:

  The interpretation of NameQualifier, and the NameIdentifier's content
  in the case of a Format not specified in this document, are left to
  individual implementations.  Regardless of format, issues of anonymity, 
  pseudonymity, and the persistence of the identifier with respect to the 
  asserting and relying parties, are also implementation-specific.

 - RL "Bob"




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC