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
- From: Heather Hinton <hhinton@us.ibm.com>
- To: security-services@lists.oasis-open.org
- Date: Tue, 2 Aug 2005 12:24:16 -0500
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]