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

[Anil Saldhana <Anil.Saldhana@redhat.com>]

On 05/18/2010 12:23 PM, Anil Saldhana wrote:
> 1) Roll Call
>
> Voting Members:
> Nathan Klingenstein      Internet2
> Thomas Hardjono     M.I.T.
> Frederick Hirsch     Nokia Corporation
> Thinh Nguyenphu     Nokia Siemens Networks GmbH & Co. KG
> Hal Lockhart     Oracle Corporation
> Emily Xu     Oracle Corporation
> Anil Saldhana     Red Hat
> David Staggs     Veterans Health Administration
>
> Members:
> Phil Hunt     Oracle Corporation
> Ari Kermaier     Oracle Corporation
     Frederico Rossini Telecom Italia
>
> Quorum: 8 out of 14 voting members (57%)
> Status: Phil Hunt and Ari Kermaier get voting rights. Tony Nadalin 
> loses voting rights.
>
> On 05/18/2010 12:07 PM, Nate Klingenstein wrote:
>>> 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.
>
> ---------------------------------------------------------------------