[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [saml-dev] "previously established an identifier usable by the requester"?
> A strict read, I think, implies that: > > * For each principal, an IDP must keep state about what > identifier, if any, it has used to represent that principal > to any particular SP. Yes, but that "state" could be "all my principals are represented by X.500 DNs or email addresses and I don't care who the SP is". Which would (to my understanding) reflect a lot of current SAML 1.1 practice. Personally, I think it's the IdP's perspective that's relevant, not the SP's. But to the extent that an IdP is creating identifiers/mappings on demand (with principal consent, for example), that's what AllowCreate applies to. If you're not doing that, then no, I think the flag is mostly irrelevant because identifiers aren't "created" because an SP wants them to be, they exist independently of that. That's why it's clearer with persistent because it's a mapping. But all identifiers are ultimately mappings. Some just have traditional behavior outside of SAML. The one case that's weird is transient, since that's strictly speaking always on demand, so the flag is required to be true given that we didn't call that case out. > * For a given principal and SP pair, if the IDP hasn't > already established an identifier to represent that principal > to that SP, then it cannot do so unless the AllowCreate flag > is set to 'true' in the <AuthnRequest>. That's strictly true, but again, it depends on the process by which an implementation "establishes" such an identifier. > * Once such an identifier is established to represent a > principal to an SP, the IDP must use it consistently in the > future (until it's changed or terminated). Definitely not true (in core). The IdP can do whatever it wants. If I send email address today and X.500 DN tomorrow, that's up to me. Unless the SP specifically asks for something else (or indicates in metadata it only supports one or the other, etc.) Now, does that make a lot of sense? Probably not for account linking, but that's a deployment decision. > This would allow SPs to link accounts, or not, at their own > discretion but independent of the name id format used. *That* was my original point. From the SP side, the format is entirely irrelevant. All that matters is that the IdP be consistent, because that's a requirement of that use case. > AllowCreate attribute. In the "basic use case" requirements > it was clearly stated that for the <NameIDPolicy> of an > <AuthnRequest> "an AllowCreate attribute is OPTIONAL, but if > sent must be set to false" and that the format value must be > 'X.509'. That would certainly be a typical situation, because X.500 names are generally *not* created on the fly. > In the "optional use case" requirements the format > was required to be 'persistent' and the AllowCreate attribute > was required to be set to true. Where in the basic use case > did the IDP "established an identifier usable by the > requester"? The second the IdP was told to treat X.500 names that way. The problem isn't so much that it's vague, it's that the number of potential knobs is enormous because the range of use cases is. Trying to codify rules to reduce the number of knobs is an implementation choice, but it's not one the spec imposes. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]