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: Minutes for July 13 SSTC Call


  AGENDA:

1. Roll Call & Agenda Review.

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


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