[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Proposed erratum resolutions
On Apr 2, 2005, at 6:03 PM, Scott Cantor wrote: >> 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. > > If that was the only issue, the SP could just use IsPassive (which was > my > reasoning for leaving the flag out originally). > > There's a distinction being created here that involves "federation as > verb", > something I wasn't in favor of the spec encompassing, but as it has, > the > question is whether creating a transient identifier qualifies. I think > it > doesn't, unless there's a persistent attribute sent along with it, but > AllowCreate (and its Liberty ancestors) pertains to the NameID only. > > The ability to use attributes like that is one reason I don't think > AllowCreate=false is all that useful. As it stands now, it doesn't > preclude > the IdP from peristently identifying the principal to the SP. It's an > IdP > issue and I wish it had have stayed one or been addressed through > higher > level profiles involving the Consent attribute. Yeah, I agree that this could have been handled more cleverly with processing rules around the consent attribute (that was a later addition to Liberty, to meet legal auditing requirements, and it probably wasn't folded into the rest of the spec as well as it could have been). The good news is that the IDP is always free to reject an AuthnRequest based on any policy that it wants, so an IDP implementation that wanted to differentiate on strong privacy protection for consumers could make decisions based on the value of the consent attribute. I think AllowCreate is there more to protect the SP in the case that it's trying to provide a better user experience by doing a "passive" AuthnRequest when an unknown user first hits the site. By "protect", I mean that the SP doesn't want to "get in trouble" by requesting that "persistent" identifiers be assigned until users have explicitly clicked through some acknowledgment of the SP's privacy statement, but it still needs a way to passively authenticate users that have already clicked through. So, it's a very subtle point, but I think you can look at the consent attribute as providing a hook to implement policy defined by the User / IDP and the AllowCreate flag as providing a hook to implement policy defined by the SP. >>> PE6: Encrypted NameID >> >> 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. > > Well, my reasoning for this wording is that it's a clarifying rather > than a > spec change (as this would be), and I think it's overly limiting to > force > the use of encryption to be established out of band when there's > already > metadata that can communicate the plaintext options out of band. Note > that > "encrypted" is not a real format, and would not show up in metadata in > the > NameIDFormat element. Perhaps also something we could clarify, but > that's > why I was careful not to put it in section 8.3. Fair enough. I'm not sure what the use case is for the SP to request and ID encrypted for itself, but that's another matter. -Greg > > -- Scott > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]