RE: [security-services] Re: Proposed Agenda for SSTC Call (May 18, 2010)

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

> From my recollection, the goal Phil had in mind is to allow the SP to
> reconcile its own information with the operation results at the IdP, e.g.
> supplying an identifier in the other direction so the SP can update its own
> representation of the user, possibly creating pairwise persistent
> pseudonyms.  Is there another way you'd prefer that the IdP signal to the SP
> that the create operation was successful, or do you feel there is no need to
> relay that information?

I haven't really understood the use case to begin with, so I'm not in a position to judge.
 
> Sleeping on it, I did think of a concern in using an AuthnRequest with an
> assertion in an extension.  Since all extensions are considered non-critical
> in SAML, how would you distinguish between an IdP that understood the entire
> request and submitted a response that success had been achieved, versus a
> (potentially poorly implemented) IdP that was able to authenticate the user
> somehow and just processed the AuthnRequest per usual and sent a Response
> back to the SP?

You can use metadata to tell the difference between an endpoint that supports the extension and one that doesn't. You could also profile an extension back in the Response direction that signals something about it. Or use secondary status codes, etc.

> Modeling the flows with an unsolicited response with an embedded
> AuthnRequest in an extension would seem to me a safer way to ensure that the
> provider really understands what it has received and what it's supposed to
> do with it.

Except that "safe" in that case probably would mean an inability to respond and the user would be stuck at the IdP. SPs don't like that.

-- Scott