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: FW: Draft minutes SSTC 2010-07-27

FYI. Minutes from last meeting on 27 July 2010.

Big thank you to George.


-From: George Fletcher [mailto:george.fletcher@teamaol.com] 
-Sent: Tuesday, July 27, 2010 1:07 PM
To: Anil Saldhana; Thomas Hardjono
Subject: Draft minutes SSTC 2010-07-27


Was wondering if you would mind taking a look at these and seeing if they pass muster:) I can try and summarize if this is too wordy.


SAML meeting 2010-07-27


Minutes Approval
* Motion: Rob Philpot
* Second: Tony Nadalin(?)
* Approved by unanimous consent

Item 4.a:
* No current electronic ballots

Item 4.b:
* No status/notes regarding past ballots

Item 4.c:
* Waiting for Mary to set up Holder-of-Key web browser profile.
* AI: Thomas to contact Mary

Item 4.d:
* Thomas asked Mary to copy data into the doc tree

Item 4.e:
* Can accommodate the request with the attribute profile
* Use the attribute request to return the kerb cred blob
  - cred structure needs to contain a ticket for the subject to access a different service
  - asking the SP for a ticket access a further downstream service (e.g. IMAP ticket)
* More information on the security-service-comments mailing list
* Thomas can forward for those interested
* Request for detail regarding the original use case.
  - original use case is that the SP is querying the IdP for a ticket for itself
  - in the CMU use case, the SP is querying the IdP for a ticket (app-rec) for a different downstream service
* How to protect the credentials (determining keys for encryption) is left out of scope
  - may need to push a session key inside the attribute structure
  - desire is to not use the attribute request as a way to do key negotiation
  - important to know if the key has to be determined outside the kerberos cred structure
* The SP will use the received creds to talk to the kerberos service "natively"
* Not part of the browser SSO flows
* Flow: front-channel through attribute-push

Item 4.f:
* Scott uploaded a new working draft
* Substantial changes have been made to this document
* A new review cycle will be required
* Maybe go to CD at next call

Item 4.g:
* Updated new draft uploaded: Notify protocol
  - follows on previous discussion (add/modify)
  - to address subject managment
* Similar use cases in "cloud" environments
* Notification model where a change is "identified" and services that care can come get the change
* Provisioning can be done via SAML msgs or SPML (for large changes)
* SSO Profile is not sufficient for all needs
  - data exchanged at a provisioning event is different from a SSO event
* Issues from the document
  1. Top of page 16: NSN wanting to insert a change notification in the middle of an SSO event
     - SP identifies subject (Tim) in the auth request and the IdP returns a different subject (Tom)
     - may not need anything more than the existing web SSO profile
  2. SP needs to introduce a new subject to the IdP (e.g. SP provides imei(?) number to IdP)
     - change notify makes sense in this case
* Protocol is simple: data is just subject identifiers for notification messages
* Section 4 covers application to the SSO profile
  - change notify message allows the IdP to inform the SP as to which attributes will be returned
  - allows a smaller set of attributes to be returned for report SSO events
* NSN walked through the current use case in the document
* Looking for feedback from the TC
  - revisit in a couple of weeks

Item 4.h:
* No updates. Holding at CD.

Item 4.i:
* Use case deals with delegation
* Scott followed up offline
* No other updates

Item 5:
* IETF BOF (update from Scott)
  - gave use case presentations
  - presented some solutions
  - discussion of working group charter
  - two proposed SAML mechanisms for SASL
  - some concern of Moonshot being proposed as the only solution
    - need to be clear in the charter as to what's up for discussion
  - a way to adapt radia/aaa infrastructure to application security
  - next step is to define working group charter

Item 6:
* By end of Aug. need to determine if a face-to-face should be held at the Sept. OASIS conf

CCOW -- Clinical (didn't get the rest)
- hl7 -- international Standard
  - leverages SAML

Chief Architect                   AIM:  gffletch
Identity Services Engineering     Work: george.fletcher@corp.aol.com
AOL Inc.                          Home: gffletch@aol.com
Mobile: +1-703-462-3494           Blog: http://practicalid.blogspot.com
Office: +1-703-265-2544           Twitter: http://twitter.com/gffletch

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