RE: [security-services] Proposed erratum resolutions

["Scott Cantor" <cantor.2@osu.edu>]

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

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

-- Scott