OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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.


> -- 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 
> 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]