Re: Proposed Agenda for SSTC Call (May 18, 2010)

[Nate Klingenstein <ndk@internet2.edu>]

>3. Approval of minutes from last meetings:

>Minutes from SSTC Call on 4 May 2010:
>http://www.oasis-open.org/apps/org/workgroup/security/email/archives/201005/msg00011.html

Hal moves to approve the minutes from the prior call, and Anil seconded it.  There were no objections, and the minutes were approved.

>  (c) SAML V2.0 Holder-of-Key Web Browser SSO Profile Version 1.0 as a CS
>       - Status: Thomas has formally asked Mary for new Ballot. (3/11th)
>       - Status: Mary has acknowledged, and is setting up ballot currently. (4/15)
>       - Status: Thomas has followed-up again with Mary to request Ballot (May/14th).

Thomas has not heard back on his newest follow-up with Mary.

>  (d)  SAML V2.0 Holder-of-Key Assertion Profile Version 1.0
>       - Status: CS-01 version of this doc is on WiKi.

[AI] Thomas will make sure this goes into the OASIS Doctree as well.

>  (e) Kerberos related items. [Josh/Thomas]
>        - Kerberos Web Browser SSO Profile: 
>        - Status: In 60-day review.
>
>  (f) Expressing Identity Assurance profile for SAML2.0 (LOA) 
>        - Status: In 60-day review.

Please review these profiles and comment if necessary.

>  (g) Older docs: Thomas has formally asked Mary to post these 4 docs (3/11th)
>        (I) Protocol Extension for Third-Party Requests (CS-01)
>       (II) Protocol Extension for Requested Authentication Context (CS-01)
>       (III) Shared Credentials Authentication Context Extension and Related Classes (CS-01)
>       (IV) Text-based Challenge/Response (CS-01)
>      AI: Thomas to request Mary again (Thomas AI from May/4th SSTC Call)

Still waiting.

>  (i) NSN Attribute Update proposal (Thinh) - updates
>       http://www.oasis-open.org/committees/download.php/37601/saml-2.0-mgmt-draft-02.zip

Phil and Thinh brought their ideas back to the group without full formalization because they wanted to capture the excellent ideas that had been presented last call.

When a SP wants to provision a user in the modified model, the SP becomes its own quasi-IdP.  The SP sends an unsolicited SAML <Response> with intent to provision to the target IdP.

He was then concerned about, in step 6, how the SP indicates this action.  In a normal SSO sense, you would use a RelayState to indicate where the user was bound for.  We want to do provisioning instead, though, and it's not clear where that provisioning would be performed by the IdP.  Scott prefers use of an extension to the response as part of profiling the communication rather than using RelayState.

The IdP would then process the claims received in step 6 and either provision a new user account, or associate the Response with another account that already exists and is separately authenticated.  The means by which the IdP does this is likely to be out of scope for the profile.

Following that, there's a Response sent from the target IdP to the originating SP.  The SP, expecting this response, could either accept this as success of provisioning, or changing the identity information or identifier located at the SP.

Thinh is most interested in the use case where the SP is facilitating the user swapping primary IdP's by reprovisioning itself into a new IdP.  But Nate doesn't want to see the set of use cases constrained too much, because he sees this general set of flows as very useful for a variety of scenarios.  One is Thinh's, but he also thinks that attribute aggregation and initial provisioning of an identity would be other use cases.

Deleting an account after this front-channel provisioning could be accomplished using the back-channel provisioning flows that NSN and Oracle had initially submitted to the group.  Thinh now believes the AddSubject operation in that document should be shelved for the time being, focusing on the present front-channel approach to subject creation.  The back-channel work in that document is still important and represents a separate but closely related profile.

Nate and Thinh agree that the designation of SP's and IdP's in the proposal is a little arbitrary.  Both providers are required at different points in the flow to act as either an IdP or an SP.  The proposal could probably be generalized in order to allow for initiation of the flows at an IdP as well.  Nate preferred that both entities simply be called "providers".  Phil will think about this and consider another approach to diagramming it.

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. 

There was also discuss about whether the secondary Response back to the SP was a requirement.  Nate thought it was an elegant way to either report successful provisioning or allow the SP to modify its own representation of the user, all using an existing protocol.  Using an embedded AuthnRequest that Scott proposed on the email list could be a nice way to associate the IdP's new Response with the initial provisioning Response.  Upon receiving the Response, the SP could initiate other actions as required to fulfill its use case.  It may be that the second Response is indeed optional, but Nate felt this would only become apparent after more concretely profiling the flows and applying them to some use cases.

>  (j) Metadata Interop profile (Scott) - updates
>      Status: Scott waiting for comments from ICAM folks.

Scott was absent today, but Thomas believes that Scott is still waiting.

>6. Assorted threads on saml-dev/comment list:
>   - SP initiated authentication and provisioning.
>   - Call for Presentations for OASIS Identity Management 2010 Conference   

There is a chance to hold a face-to-face meeting of the OASIS-SSTC at this conference, on the 27th and 28th of September.  Thomas asked folks to note this in their calendars.

Hal has concerns about the cost and cut-off time.  A decision should be reached before that.