Re: [security-services] Forwarding thread on "previously established an identifier usable by the requester"?

[Greg Whitehead <grw@trustgenix.com>]

On Apr 5, 2005, at 9:52 AM, Scott Cantor wrote:

>> I believe it should be the principal. If the IDP assigned NameID is
>> updated, you shouldn't throw away the SP assigned NameID.
>
> Not quite my intent. If you modify the NameID, sure. What I mean is 
> other
> formats. For example:
>
> IdP assigns "persistent" NameID
> SP registers SPProvidedID
> IdP uses existing X.500 DN NameID
>
> Does the X.500 NameID contain the SPProvidedID? I would say it's up to 
> the
> IdP and would be legal either way.

I see. Sure, I think we've said that NameID Management only applies to 
persistent ids.

>> While it may be true that attributes may foil the use of pseudonyms in
>> persistent or transient NameIDs, by revealing too much information,
>
> Not necessarily, the attribute itself might just be a persistent 
> NameID, or
> equivalent.

Well, that in itself can foil pseudonymity if the scope (lifetime and 
sharing) of that persistent attribute is greater than the NameID.

>> I don't see how they render AllowCreate pointless. The point of
>> AllowCreate is to prevent an assertion from being generated
>> in response to an AuthnRequest under certain circumstances: namely, 
>> when
>> the requester has not already been assigned a persistent identifier 
>> for
>> the user (in-band from a previous authentication, or out-of-band by 
>> some
>> other means). In other words, AllowCreate=false is meant to prevent 
>> the
>> requester from learning a persistent name for a user that they don't
>> currently already know.
>
> Right, but it doesn't. An IdP is allowed to issue a transient NameID 
> in an
> assertion with an attribute that is persistent (could be an IdP 
> assigned
> pseudonym, could be something else) in response to an AuthnRequest with
> AllowCreate false. So what does it prevent?

Well, there are lots of ways for an IdP to screw up, so I'm not sure I 
buy your argument. AllowCreate, for better or worse, talks about the 
NameID and it's up to the IdP to ensure that it doesn't subvert the 
work done managing NameIDs by breaking privacy in some other way. 
Perhaps we can simply say that the IdP should take care when including 
attributes in assertions using 'persistent' or 'transient' NameIDs so 
as not to thwart the privacy protections that they are attempting to 
afford.

> Sure, this is use case specific. But that's the point. Without knowing 
> the
> use case, you don't know how to set the flag or what it means. I 
> contend
> that it's not a "format" issue, but a use case issue. As we agreed,
> "persistent" in and of itself doesn't imply dynamic. Nor does, IMHO, 
> X.500
> imply static.
>
> So, the formats themselves don't have processing rules pertaining to
> AllowCreate. It's a deployment specific issue that isn't visible in 
> the SAML
> spec. I think that's what Brian was concerned about.

So, perhaps the mistake was moving the ID-FF 'federate' flag into SAML 
NameIDPolicy and calling it AllowCreate? I think we need to focus on 
explaining what was intended and not reverse engineering what's implied 
by the syntax that we ended up with.

> If we can reach some kind of consensus on that, then at least there's 
> a way
> to explain it to implementers, even if they don't like it. ;-)

Agreed.

-Greg

>
> -- Scott