Re: [security-services] Minutes for July 13 SSTC Call

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

  On 07/13/2010 12:31 PM, Paul Madsen wrote:
>  AGENDA:
>
> 1. Roll Call & Agenda Review.
>
Voting Members:
John Bradley  Individual
Nathan Klingenstein Internet2
Thomas Hardjono M.I.T.
Anthony Nadalin Microsoft Corporation
Thinh Nguyenphu Nokia Siemens Networks GmbH & Co. KG
Hal Lockhart Oracle Corporation
Emily Xu Oracle Corporation
Anil Saldhana Red Hat

Members:
Paul Madsen NTT Corporation
Federico Rossini Telecom Italia S.p.a.

Status: Ari Kermaier lost voting rights.
Quorum: 8 out of 14 (57%)
> Quorum met
>
> 2. Need a volunteer to take minutes.
>
> Paul will minute
>
> 3. Approval of minutes from last meetings:
>
> Minutes from SSTC Call on 29 June 2010:
> http://www.oasis-open.org/apps/org/workgroup/security/email/archives/201007/msg00000.html 
>
>
> John B moves to approve, Hal seconds.
>
> No objections, minutes approved
>
> 4. AIs & progress update on current work-items:
>
> (a) Current electronic ballots: None
>
> (b) Status/notes regarding past ballots: None.
>
> (c) SAML V2.0 Holder-of-Key Web Browser SSO Profile Version 1.0 as a CS
> - Status: New ballot has been requested. Still awaiting.
> http://www.oasis-open.org/apps/org/workgroup/security/email/archives/201006/msg00032.html 
>
>
> Did not have sufficient votes 3 weeks ago. Pending with Mary
>
> Hal notes that OASIS had email problems a week ago. Some messages may 
> have been lost.
>
> Thomas will follow up with Mary to confirm
>
> (d) SAML V2.0 Holder-of-Key Assertion Profile Version 1.0
> - Status: CS-01 version of this doc is on WiKi.
> - AI: Thomas to ask Mary to move into Doc tree.
> - Status: Awaiting Mary.
>
> Thomas needs to follow up with Mary to move document
>
> (e) Kerberos related items. [Josh/Thomas]
> - Kerberos Web Browser SSO Profile:
> - Status: Public review period closed on 15 June 2010.
> - Status: Comments received for Attribute profile. Spec will be updated.
>
> Thomas and Josh received comments from Carnegie Mellon - an 
> interesting use case. Will update attribute profile spec
>
> Dialog is on comments list for SSTC
>
> (f) Expressing Identity Assurance profile for SAML2.0 (LOA)
> - Status: Public review period closed on 13 June 2010.
> - Status: Awaiting comments/resolutions.
>
> Paul, Scott and I reworking, will be uploaded in near term
>
> Hal, OASIS process requires that , perhaps at CS status, that all 
> comments are acknowledged and addressed. As a courtesy, we could 
> respond through email to commenters
>
> (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)
> - Status: Posted.
>
> http://docs.oasis-open.org/security/saml/SpecDrafts-Post2.0/sstc-saml-protocol-ext-thirdparty.html 
>
> http://docs.oasis-open.org/security/saml/SpecDrafts-Post2.0/sstc-saml-protocol-ext-rac-cs-01.html 
>
> http://docs.oasis-open.org/security/saml/SpecDrafts-Post2.0/sstc-saml-context-ext-sc-cs-01.html 
>
> http://http://docs.oasis-open.org/security/saml/SpecDrafts-Post2.0/sstc-saml-text-based-challenge-response-authn-context-class-cs-01.html 
>
>
>
> (h) SOA-TEL Token Correlation Profile (Federico/TI)
> http://www.oasis-open.org/committees/download.php/38374/sstc-saml-token%20correlation-profile-v0.8.pdf 
>
>
> Federico & colleague will explain.
>
> Document defines the syntax to express a relation between two SAML 
> assertion, a “main”
> one and a “related” one.
>
> The syntax defined defines a new security profile, in which a SAML 
> assertion is
> syntactically and semantically meaningful if it is presented in 
> relation with another “related”
> SAML assertion; it enables to express a relation between two security 
> SAML assertions
>
> 1. the SAML assertion cannot be built and considered valid if it isn't 
> presented together with
> another “related” SAML assertion,
>
> 2. The authorization is granted only in presence of both the subjects 
> of the two SAML assertions.
>
> Motivated by complex business processes
>
> Thomas asks 'would it be simpler if the first assertion were hashed, 
> and the hash inserted into the second, both sent to SP?
>
> Federico - yes but we want to be able to express constraints on the 2 
> subjects of the 2 assertions.
>
> Thomas, is it not already possible to embed one assertion in another?
>
> Hal, you could put one assertion into the Advice of another. But not 
> clear what semantic Federico is hoping to express with the embed?
>
> Thomas, believe they want an intermediary to hold onto SAML1 for a 
> long running process, and when appropriate, be able to get a SAML2 
> assertion (with SAML1 within)
>
> Hal asks, why must they be embedded, why not simply have both assertions?
>
> Federico, simply require a strong link between the two assertions
>
> Thomas, existing <Advice> element allows embedding assertions?
>
> Federico, more important than the syntax,
>
> Nate, for SAML 1.1, is there not an issue with being able to sign an 
> assertion? whcih would complicate this?
>
> Hal, thinks SAML 1.1 does allow
>
> Thomas, actually they are using SAML 2.0, just lisleading the labels 
> on the diagram
>
> Nate, if the goal is to strongly link two assertions, you can embed, 
> or point from one to the other
>
> Hal, is the linking fundamental?
>
> Nate, believe you cannot use the 2nd assertion without the first
>
> Paul, but <Advice> doesnt provide that semantic, better would be 
> <Condition>?
>
> Nate, most important is how to represent the relationship from one 
> assertion to another.
> Another issue to consider is how to avoid pointing to expired 
> assertions, need to ensure that the lifetime of the first assertion 
> exceeds the business process duration
>
> Federico, yes noted
>
> Paul, is the different audiences of the two assertion another issue?
>
> Nate, the delegation profile of Scott's could help here.
>
> Hal, dangerous to allow for ignoring an expiration time
>
> Nate, uncomfortable with an SP ignoring the mandatory assertion checks
>
> Hal, sounds more like a WS-Security use case....Dependency is in the 
> context of this particular transaction, where signatures over messages 
> could better express the semantic of the dependency
>
> Nate, we want to keep the assertion as representing identity
>
> Thomas, summary is that the assertions talk about the subjects 
> (requestor and intermediary). The assertions dont carry enough info 
> about the context of the transaction. perhaps easier to epxress the 
> dependencies in WS-Sec.
>
> Federico, but what is the <Conditions> for if not this sort of thing?
>
> Nate agrees, thinks the assertions are being used for a 
> capability/privilege model,
>
> Rob, Conditions can be anything, you define a new element of the 
> ConditionType and extend appropriately
>
> Nate, Consensus is that <Conditions> is the appropriate soln for 
> expressing the Token-Correlation,
> Could be either a pointer, or embedded. Both assertions should be 
> valid when received by the SP
>
> Thin, Believe the proposal is to deal with expired assertions? SP 
> requests an extension?
>
> Nate, dont think so, believe expiration is a separate problem. Core 
> aspect for this use case is 'Validity of Token 1 depends on Token 2'.
>
> Thomas, can Federico come back and give an update?
>
> Feerico, yes, let me know when
>
> (h) NSN Attribute Management proposal (Thinh/Phil) - any updates?
>
> Phil indicated there would be an update posted soon
>
> (i) SSO initiation CD (Scott) - any updates?
>
> 5. New work items:
> - Project Moonshot (potential new work item)
> - IETF Federated Authentication BOF (at July IETF meeting)
>
> Hopefully Josh Howlett can brief us someday
>
> 6. Propose an SSTC Face-to-Face meeting for September 2010:
> - Awaiting for room confirmation.
>
> Still waiting to determine if we can get a room
>
> 8. Next Call: Tuesday 27 July, 2010.
>
> Nate moves to adjourn, Hal seconds
>
> Adjourned