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: [security-services] Proposed erratum resolutions


I can understand wanting to keep format specific processing rules out of
the specification but, at this point, I'm not sure it's appropriate.  I
completely agree with Scott that this needs some further discussion and
treatment in errata.  I've focused primarily on the AllowCreate
attribute but I think the issue is bigger and involves just about
anything that can potentially have different interpretation that are
dependent on name id format.  

-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Saturday, April 02, 2005 3:09 PM
To: security-services@lists.oasis-open.org
Cc: jmoreh@sigaba.com
Subject: [security-services] Proposed erratum resolutions
...

---

PE5: Rules for NameIDPolicy

Probably needs more discussion in light of Brian's recent posting of
other
concerns about AllowCreate to saml-dev, but the erratum is specifically
addressing transient.

I see two options, the strict reading and the "common sense" reading.
Either
involves adding text after line 2147 of [SAMLCore].

Strict:

"Finally, note that since the
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent Format value (see
Section 8.3.8) implicitly results in a new identifier being created
during
the handling of most requests, the AllowCreate attribute MUST be set to
true
in order for such a value to be returned."

Optimized:

"Finally, note that since the
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent Format value (see
Section 8.3.8) implicitly results in a new identifier being created
during
the handling of most requests, the AllowCreate attribute MUST be ignored
by
the identity provider when such an identifier is requested or issued."

I favor the latter. I also agree with Brian that we need more guidance
on
what the point of AllowCreate really is. I think it's hard to separate
it
from the issue of "consent", personally, and might have been better
handled
with processing rules based on the Consent attribute, but that's water
under
the bridge.

I do think the practical meaning of AllowCreate is potentially format
specific, so it might be best just to acknowledge that.


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