Re: [security-services] Proposed erratum resolutions

[Greg Whitehead <grw@trustgenix.com>]

On Apr 2, 2005, at 5:03 PM, Greg Whitehead wrote:

>
> On Apr 2, 2005, at 4:09 PM, Scott Cantor wrote:
>
>>
>> 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.
>
> The Liberty use case that resulted in AllowCreate was the desire to 
> "passively" probe for an authenticated user without the chance of 
> either (a) the user being prompted for authentication by the IDP or 
> (b) the user being prompted for federation consent if they were not 
> already federated. So, I believe your first suggestion is the one that 
> was intended.

Sorry, missed your comment about consent -- you're right that it's tied 
in and I suppose AllowCreate could have been handled with processing 
rules on the consent attribute. As it stands, if the SP is passively 
probing for an authentication without any form of consent, AllowCreate 
can be set to false to prevent a new federation from being created. If 
that fails because the user has not yet federated with the SP, the SP 
can then explicitly offer the choice to establish a federation and 
allow seamless SSO in the future.

-Greg