[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes for 8-Mar SSTC focus call
Dial in info: +1 865 673 6950 #351-8396
RL “Bob” Morgan
1. Editorial issues re: packaging SAML 2.0 docs for
- Rob: Working with OASIS to obtain persistent URL’s for specs so we can use them in the IANA memo’s in the appendices.
2. Recent threads:
a. Possible compromise on profile language (on Rick’s proposed profile)
AI: Rick will be responding with a new draft of X.509 profile that takes the proposed compromise into account.
- Scott: there’s no metadata for queries. Grid community is also interested in the use of the attribute queries. How is this profile going to be linked to metadata. The ds:KeyInfo is at the role level and there are no roles for the query support. Should we consider doing this in the MD?
- Rob: As part of a V2.1?
- Scott: Why not do it as a separate document on a CD track and eventually roll it into 2.1.
- Rick: how would this be handled?
- Scott: as a separate document with the MD extensions described.
- Greg: Is this a role within an entity or a type of service provider?
- Scott: It’s a role.
- Greg: to be clear – it’s a bucket to put a KeyInfo in, right?
- Scott: yes.
AI: Scott – propose an MD extension for query client and query responder roles.
b. Potential Errata
- Consensus is to add an errata to clarify the SLO/federation termination session termination confusion.
- Greg: if a use goes to a management page at an SP and terminates their federation with an IDP, we don’t state what should happen.
- Tom: I believe a session should be orphaned after a terminate operation.
- John: Do we want to include some of this info in the Technical Overview?
- Rob: is this too detailed? Does it belong in implementers guide?
- Scott: probably in both. Some of this is deployment, so Tech Overview may be most appropriate for that.
- Paul: what if the termination is at an administrator’s request? Should sessions be orphaned?
- Tom: Perhaps do a logout first and then terminate?
- Prateek: Sounds like a number of cases should be described and discussed.
AI: Tom – propose some text to clarify the interaction for the SlO/termination use cases.
- Tom: re: AuthnRequest signing flags.
- Scott: The metadata flags don’t come close to covering the needs here.
- Prateek: Appeared to reach closure. Is there anything to further document?
- Scott: it’s not an errata issue. It should probably be a FAQ entry. Perhaps some info should go in the implementers guide.
- no action needed.
3. SAML 2.0 Supporting Documents
a. Executive Overview
- Eve would like the token from Paul to make edits from her recent review.
- Paul will send her the doc source.
b. Technical Overview
- John: 2 items left: 1) explain basic federation use case and 2) Eve’s section on 1.1/2.0 differences.
- Eve will be calling John tomorrow.
c. Implementation Guidelines (from August 2004)
- Prateek: this document is orphaned. It will likely just have to wait.
4. Other docs on CD track
a. SAML 1.x metadata
- Scott: published an update today and would like it to go for a vote next week.
- Scott: I’ve implemented and tested this profile.
AI: Chairs to put saml1x metadata doc up for a CD vote at next meeting.
b. X.509 Authn-based Attribute Profile
- Discussed earlier
c. Response to analysis of Artifact Profile
5. Other business:
a) Scott just sent out mail re: trust validation so folks can take a look at it.
b) Scott asked when/how the new OASIS IPR policy would affect us.
- Rob: the policy is now in affect since it has been approved by the board. The transition period can take up to a couple of years. When a TC transitions to the new policy depends on their stage of activity.
AI: Rob – will send pointers to the new IPR policy and the transition policy for all TC members to read. We’ll add an agenda item to an upcoming con-call to discuss the policy and what it means for our TC (what mode we wish to operate under, when do we want/need to transition, etc).
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com