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 Authentication Assertion correct?


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

I reluctantly agree with Tom, not because I don't want to agree with Tom,
but because I hate the fact that the spec was written this way. I think it's
silly. But what section 8.3.2 says is:

"Indicates that the content of the element is in the form of an email
address."

That's it. Nothing about it *being* an email address. If I'd noticed that, I
would have argued that we should change it, but of course we'd have had to
orphan the 1.1 format.

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

That's the corollary...I think all the old formats are mostly worthless
precisely because they don't.

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

I simply see it as a function of the guarantees/implications of the Format.
Those two have some, the rest don't. Ergo two formats are useful and the
rest aren't so much.

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

Right.

-- Scott



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