Re: [security-services] Proposed erratum resolutions

[Greg Whitehead <grw@trustgenix.com>]

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.


> PE6: Encrypted NameID
>
> [SAMLCore]
> Append to paragraph ending on line 2139:
>
> "It is not possible for the service provider to specifically request 
> that a
> particular kind of identifier be returned if it asks for encryption. 
> The
> <md:NameIDFormat> metadata element (see [SAMLMeta]) or other 
> out-of-band
> means MAY be used to determine what kind of identifier to encrypt and
> return."

It might make more sense to say that the IDP should be in charge of 
deciding whether to encrypt the ID or not and have the SP always 
request the particular kind of ID it wants. In other words, disallow 
use of "encrypted" in request name id format.

-Greg