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 con-call, August 2, 2005



Here are the minutes. I had a hard time keeping up with who said what (you all talk to quickly when you are excited). Can you please review and make sure that I have recorded what you think you said?

1.Attendance/call to order.


<minutes>
See Steve's notes re: attendance
We have 20 out of 28 voting members as of initial roll call, so we have quorum
Some notes on membership and voting status:
Step 1: Request TC membership (requires approval from the official company rep to OASIS)
Step 2: Once TC membership granted, must additionally and separately request voting member status
Step 3: Attend three meetings in a row to get voting member status
Step 4: Continue to attend, attending at least two out of every three meetings to keep voting member status
</minutes>

2. Approve minutes from July 19th conference call.
http://lists.oasis-open.org/archives/security-services/200507/msg00047.html
Approved without objections

3. New drafts: sstc-saml-tech-overview-2.0-draft-07-diff.pdf

http://lists.oasis-open.org/archives/security-services/200507/msg00051.html

Needs review of the new bits!


<minutes>
Major new draft is the Tech Overview posted by Eve several days ago. We need reviews. There is a diff pdf posted to allow for easy call out of new content.
There is update required to XML and other items of Tech Overview - Eve has accepted ownership of this item for now.
</minutes>

4. Errata Review  sstc-saml-errata-2.0-draft-12.pdf

http://www.oasis-open.org/apps/org/workgroup/security/download.php/13841/sstc-saml-errata-2.0-draft-12.pdf


5. New threads (some were deferred from last call)

(a)       Conor: SAML error processing text:4 (see Errata PE19)  
http://lists.oasis-open.org/archives/security-services/200507/msg00008.html    

<minutes>
Prateek: This a prospective errata item. There has not been much response to this item (contains some proposed changes to binding error responses).
Jahan: This has been added and we can take a vote on accpeting this as an errata.
Prateek: Call of objections - hearing none, the changes as specified in the errata document will be adopted. This is now closed.
</minutes>
                         
(b)       Conor, et al: List discussion re: Using SAML Artifacts in the
WSS SAML Token Profile
http://lists.oasis-open.org/archives/security-services/200507/msg00011.html

<minutes>
Prateek: From email list, it appears as if this item has closed. Is this true?
Conor: No. Action item from last meeting was for Conor to explain use case. Has explained the use case but there has been no discussion on the list since then.
Scott: SAML artifacts are no longer assertion references in the WSS spec.
Prateek: The kind of reference passing that WSS has is not adequate?
Conor: WSS has a basic STR. Does not believe that it by itself can name a token sufficiently that you get back a SAML assertion
Scott: Yes, it can. It can't communicate any additional info about semantics of token. Typically you wold pass URI binding of assertion to be received. There are no restrictions on use (one time etc).
Conor: Effectively use a URL that points to the assertion issuer and gives them an identifier that points to the assertion?
Scott: Pass a URL binding to the assertion so you don't have to pass all of the other stuff not handled well in old WSS versions. If an assertion ID is extremely hard to get, you do get something that looks a lot like an artifact.
Prateek: Do we have an action? Do we need to forward comments to WSS?
Conor: If we can do this with WSS without having to change STP then we are okay.
Tony N: It could be done with changes to the STProfile, not WSS core. STP can declare own identifiers and own semantics against these identifiers.
Conor: Do we want an STR to be able to say (in gneeral) that this is a one-time use ref
Tony: Profiles declare own identifiers. Want those profiles to define their sematnics.
Conor: This is back in STP after all. We should issue an action item to Ron (to get back at him for the last action item assigned when Conor was absent)

ACTION ITEM: Ron M to review this as changes to STP
</minutes>

(c) SSO Profile confusion
http://lists.oasis-open.org/archives/security-services/200507/msg00053.html

<minutes>
Prateek: Now that we have text, can we pass this off to Jahan?
Brian: Scott and Brian are more or less on same page re issues and how to clarify them. Are not yet at the point to write errata text.
Scott: Why is there push back on this?
Prateek: Is concern, why multiple assertions?
Scott: Why multiple assertions? Why multiple authentication statements? how do you handle them (eg what if issuer different, subject different, etc)?
Conor: In what context?
Brian: In SSO - whether everything bundled in single assertion or multiple assertions?
XXX (Brian?): We made a best guess effort for our product. We don't know if it will interop with anyone cause we have never seen it anywhere else.
Conor: Potential uses cases coming down the pipe where single assertion will result in multiple identities. In radio scenario, client device could be associated with multiple user accounts.
Brian: This is a problem that has plagued this spec - the processing rules and restrictions around this profile. We are just talking about making basic use web-SSO profile a bit more straight forward.
Scott: Tried to introduce restrictions in profile, not protocol.
Steve: Where are these changes going to be effected? This is not errata, but some sort of V.next.
Conor: Almost creating new profiles (web browser, single user, single sign-on profile).
Brian: Belief is that in current case, even with multiple assertions, they were all to refer to a single identity (thus invalidating Conor's use case?), so web browser, single user, single sign-on use case is what current spec is dealing with.
Brian: Multiple subjects should be a NEW profile.
Conor: If this is clarifying what is there/what we initially intended, it is errata. If this is something new, then this is more intrusive; changing these rules is something that can't be done in errata.

ACTION ITEM: Scott to put together some preliminary text on these errata to help jump start conversation and figure out how to "lock down" profile.

ACTION ITEM: Brian/Scott to (try) to put together a list of restrictions that "hamper" use cases to help us scope this down and the appropriate approaches to deal with this. This may well end up being input to next release.
</minutes>

(d) SAML Conformance SSL/TLS Requirements
http://lists.oasis-open.org/archives/security-services/200507/msg00041.html
<minutes>
Prateek: This is an item raised by Eric Tiffany. This is material we have had for a while - it addresses some minimum deployment configuration for SSL that SAML entities (request/responder) can reasonably expect.

ACTION ITEM: Prateek to respond to this item.
</minutes>


6.       Merritt Maxim: SAML Adoption Subcommittee Status (deferred from
last call):
http://lists.oasis-open.org/archives/security-services/200506/msg00117.html

<minutes>
Merritt: Does not yet have voting status. Once this is achieved, will clean up and bring for vote.
</minutes>

7. Open AIs

#0225: Third-party AuthnRequest use case
Owner: Scott Cantor
Status: Open
Assigned: 2005-07-04
Due: ---


<minutes>
Prateek: This stays open.
</minutes>

--------------------------------------------------------------------------------

#0224: Re-work X.509 Authn attribute protocol profile to address SSTC
comments.
Owner: Rick Randall
Status: Open
Assigned: 2005-06-20
Due: ---


<minutes>
Prateek: This is an action for Rick and Rob to update doc.
Eve: Needs to turn this into a CD form first and then they can work on this. Hopes to have this done by end Wed so they can work on this.
Eve: It would be a candidate-02 and then we can vote on it.
Prateek: This is a CD, but needs some additional work clarifying security considerations.
</minutes>

--------------------------------------------------------------------------------

#0223: Proposal for subcommittee to address enhancing SAML Adoption.
Owner:  
Status: Open
Assigned: 2005-06-20
Due: ---


<minutes>
Just discussed - see Merritt
</minutes>

--------------------------------------------------------------------------------

#0216: Formulate some suggested redline text for E7 for review.
Owner: Jahan Moreh
Status: Open
Assigned: 2005-03-30
Due: ---

<minutes>
Prateek: Is this still opne?
Jahan: Yes

--------------------------------------------------------------------------------

#0210: Links to new IPR policy to be sent to SSTC
Owner: Rob Philpott
Status: Open
Assigned: 2005-03-15
Due: ---

<minutes>
Prateek: stays open
</minutes>
--------------------------------------------------------------------------------

#0180: Need to update SAML server trust document
Owner: Jeff Hodges
Status: Open
Assigned: 2004-07-12
Due: ---

<minutes>
Prateek: Stays open - issue we are tracking
</minutes

<minutes>

Errata:
PE 20 -
Opened and closed by Jahan (took from minutes of last conference call). This was voted in

PE 22
Jahan: Reported by Rob. This is a fairly minor change to Line 907 of profile
Prateek: Call for objections to adopting PE 22? Hearing none, this is accepted as errata.

PE 23-25 are Nick's items
PE 23 - Artifact resolution service metadata item
Nick:  - this is a change to a MUST to a SHOULD. Nick has provided text in message .
Scott: Would rather clarify this with a statement ahead of this, saying that this is what you do if you use SAML metadata.
Nick: Agree with that, but need to clarify what to do if you are using metadata. Found that none of the cases said anything other that SHOULD on topic of metadata. This is the one location in doc that used a MUST not clearly qualified.
Nick: Sounds like we can't vote. Will go back and look to see if this can be fixed with a "if you are using metadata statement".
Scott: If you make it a SHOULD, it says you can use metadata but you don't have to use this element.
Prateek: This stays as PE

Post discussoin note: This refers to line 639 not line 629
Scott: Why is having a MUST a problem?
Nick: This is a recapitulation of email thread.
Scott: Look at begining of this section (618). Intent of this sentence is to communicate a MUST. It just doesn't say that.
Heather: This should say MUST otherwise we will all have this confusion
Scott: We need to do a general clean up of language.
Nick: Agreed. Will look at overall section.
Prateek: This item remains active.


PE 24 - HTTPS in URI binding
Prateek: Idea is that SSL/TLS is delegated to conformance.
Prateek: Call for objections to adopting PE 22? Hearing none, this is accepted as errata.

PE 25 - Metadata structures in conformance document
Nick: Add to conformance doc (and thus SAML conformance infrastructure) a feature that implementors could elect called "metadata stuctures" that captures out of SAML metdata spec that as an implementation "we are using this metadata structure". Doesn't say anything about use, discoverabliity, etc. Gives assurance that implementation uses this type of structure so that if metadata is currently being used, it can be re-used/re-structured to continue to use metadata. Crux is that metdata structure features are added to tables 2 and 4, these features will be optional for all kinds of operational roles and does not seem applicable to ECP roles. There is a new section added to subsection 3, clarifying metadata structures, saying "if you someone who is claiming this, then you must provide structures that use it; if you claim and reference then you must actually reference/use"
Implementors may have some beneift from listing of all cases where if they make this claim they have to support options/claims in metadata".
Nick: Is this description satisfactory?
Prateek: call for (additional) discussion
Scott: We can't claim that this be errata because we discussed this and said that it was not required for conformance. This can be errata if you are not changing any of the stuff about conformance, which I guess you can claim because this is optional.
Prateek: Nick has given description about what it means to match, to implement operation modes, the metadata structure feature.
Nick: If you say that you do it, then you must provide this data (ed note: sounds pretty obvious to me....)
Scott: But how do you make it available?
Nick: We don't care how the data is made available.
Scott: Understand consuming side a lot better than the side of peer providing metadata. There are various ways to do this, all of which are optional. If I say that I am conformant, what does this mean I have to do?
Nick: There is no way to claim in conformance that you support metadata
Scott: On the publishing side, what do I have to do/implement?
Conor: You have to pick at least one of the optional approaches. We can specify the "at least one" approach and let publisher choose to do others.
Conor: Option is to scope this so that you specify to which approach you conform (ed note: my grammar, not Conor's)
Nick: If I say that I am entity that supports this, I will put my attributes into the SAML metadata schema.
Conor: More value from conformance/adoption if we have a flag that says "we support metadata". If this flag is set, then you MUST support the well-known location approach and you MAY support other approaches.
Nick: If I do implement in some form, then I can look at any other implementation that also supports this metadata. So this will protect me from bringing on other implementations. Saying that you have to support at a minimum the well-known location is good.
XXX: Think that some of the issues have to do with the overall lack of familiarity with use/value of metadata
Prateek: We have propopsed text in errata. Do we accept that?
Conor: Is a conformance doc a normative spec?
Scott: Yes, it is.
Scott: If we think this is important, we can make it errata with the claim that we are making explicit what people have to do (and have done) for conformance.
Scott: Would like to strengthen these bullets, because even if more work, it makes it more clear what has to do.
Prateek: This stays as proposed errata. Nick will re-word/resubmit for next time.

</minutes>

Meeting ajourned at 12:22 CDT


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