security-services message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [security-services] Minutes for con-call, August 2, 2005
- From: Heather Hinton <hhinton@us.ibm.com>
- To: Heather Hinton <hhinton@us.ibm.com>
- Date: Thu, 4 Aug 2005 18:43:15 -0600
Given that no-one piped up on the attribution
of the various pearls of wisdom included below, here are the minutes with
Steve's attendance list added at the very bottom. Look down, waaaaay down.
Cheers,
heather
Heather Hinton/Austin/IBM@IBMUS
08/02/2005 12:24 PM
|
To
| security-services@lists.oasis-open.org
|
cc
|
|
Subject
| [security-services] 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.
Attendance at end of this email.
<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
Attendance of Voting Members
Abbie Barbir Nortel
Mike Beach The Boeing Company
Conor P. Cahill AOL, Inc.
Brian Campbell Ping Identity
Scott Cantor Internet2
Guy Denton IBM
Heather Hinton IBM
Frederick Hirsch Nokia
John Hughes Individual
Ari Kermaier Oracle
Hal Lockhart BEA Systems, Inc
Eve Maler Sun Microsystems
Prateek Mishra Principal Identity
Jahan Moreh Sigaba
Bob Morgan Internet2
Vamsi Motukuru Oracle
Anthony Nadalin IBM
Darren Platt Ping Identity
Nick Ragouzis Individual
Irving Reid Hewlett-Packard Company
David Staggs Veteran's Health Admin
Thomas Wisniewski Entrust
Emily Xu Sun Microsystems
Attendance of Voting Members - Probation
Paul Madsen NTT USA
Steve Anderson BMC Software
Dana Kaufman Forum Systems
Peter Davis NeuStar
Jeff Hodges NeuStar
Gilbert Pilz BEA Systems, Inc.
Attendance of Non-Voting Members
Jim Lien RSA Security
Attendance of Applicants
Merritt Maxim CA
Ashish Patel France Telecom
Membership Status Changes
Steve Anderson BMC Software - Requested
voting status 7/26/2005
Rob Philpott RSA Security - LOA 7/26
- 8/16
Eric Tiffany IEEE Industry Standards
- Granted Membership 7/26/2005
Rick Randall Booz Allen Hamilton -
Requested voting status 7/26/2005
Dana Kaufman Forum Systems - Requested
voting status 7/27/2005
Ashish Patel France Telecom - Requested
membership 7/27/2005
Peter Davis NeuStar - Requested voting
status 7/28/2005
Jeff Hodges NeuStar - Requested voting
status 7/30/2005
Gilbert Pilz BEA Systems, Inc. - Requested
voting status 8/2/2005
Paul Madsen NTT USA - Granted Voting
status after 8/2/2005 call
Carolina Canales-Valenzuela Ericsson
- Lost Voting status after 8/2/2005 call
Alberto Squassabia Ping Identity -
Lost Voting status after 8/2/2005 call
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]