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


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

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

Subject: Re: [saml-dev] Is my English description of an AuthenticationAssertion correct?

Not to veer too far off the path of what Roger's trying to do here 
(it's extremely valuable!) but:

Tom and I were talking about this issue of format vs. semantics a 
little while back.  I believe, contra Tom, that the email address 
name format is not about "mere format", but also about semantic 
interpretation, based on the following evidence from the specs.

Section 8.3 Name Identifier Format Identifiers (page 78, lines 
3277-3278) says they "refer to common formats for the content of the 
elements and the associated processing rules, if any".  To me, this 
means that urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress 
refers to a string whose processing (or interpretation, if you will) 
comes from RFC 2822 (which defines addresses as being mailboxes or 
groups of same, which conceptually "receive mail").

This take on things is, I believe, reinforced slightly by the fact 
that Section 2.2.2 of the core spec talks about the name ID format 
as a means of "classification", which would hardly be an interesting 
exercise if such classification didn't imply something about what 
you can do with the ID.

It would be possible to create an "email name ID format profile" 
that makes it crystal-clear what sorts of processing might be 
attempted, such as addressing mail to that ID -- Tom pointed out to 
me that the special cases of "transient" and "persistent" IDs 
essentially define name ID profiles.  Maybe this would be a 
worthwhile exercise for email IDs as a belt-and-suspenders kind of 
thing, but I don't feel it's strictly necessary.

This whole problem comes about, of course, because some identifiers 
conflate at least two purposes: unique identification of an entity, 
and a handle for a communications endpoint (as Peter Davis puts it). 
  Tom has pointed out to me how Shib's eduPerson construct has a 
ready-made attribute for holding email addresses, and it would be 
possible to stay entirely away from email-formatted name IDs by 
using attribute statements for that info instead -- BUT if someone 
uses one, I think it's legitimate to try to send mail to it.


Tom Scavo wrote:
> On 5/8/06, Costello, Roger L. <costello@mitre.org> wrote:
>> I, http://www.AirlineInc.com, assert that I authenticated this Subject
>> (which I identify by email address): j.doe@acompany.com
> Strictly speaking, the *format* of the NameID is that of an e-mail
> address (according to RFC 2822).  The spec does not say the identifier
> must be a resolvable e-mail address (which the above seems to imply).
> Tom

Eve Maler                                         +1 425 947 4522
Technology Director                           eve.maler @ sun.com
CTO Business Alliances group                Sun Microsystems, Inc.

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