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] Re: Proposed Agenda for SSTC Call (May 18, 2010)


> Ari asked the group to consider using an AuthnRequest to convey the account
> creation request instead of a Response to kick off the process, with an
> extension to convey attributes, as he thought there would be less profiling
> and implementation work required to do so.  Nate disagreed, because he
> believed the set of information that would be desirable includes everything
> that is in an assertion anyway; assertions are designed, after all, to carry
> and convey information about a principal from one provider to another.

Another way to approach this would be to embed an Assertion inside an AuthnRequest via an Extension as the provisioning flow, and perhaps duplicate the assertion subject into the AuthnRequest to "connect" them. That's just the inverse of my suggestion. That might be more consistent with existing flows but without fundamentally reinventing anything.

To assert something, you still have to act in an asserting party role, but it would perhaps limit the need to represent the SP as an IdP or vice versa from a protocol standpoint.

The assertion could be a standard SSO assertion with the usual confirmation data and the profiling required would be pretty minimal, just defining an extension to carry the assertion and give it meaning. Perhaps <AuthenticateAs>, or something like that.

-- Scott




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]