[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Revised minutes for 27-Sep SSTC con-call, with attendance *and membership updates*
Attending:
Voting:
Abbie Barbir Nortel
Brian Campbell Ping Identity
Carolina Canales-Valenzuela Ericsson
Scott Cantor Internet2
Heather Hinton IBM
Hal Lockhart BEA Systems, Inc
Paul Madsen NTT Corporation
Eve Maler Sun Microsystems
Merritt Maxim CA
Prateek Mishra Principal Identity
Jahan Moreh Sigaba
Bob Morgan Internet2
Cameron Morris Novell
Anthony Nadalin IBM
Ashish Patel France Telecom
Rob Philpott RSA Security
Gilbert Pilz BEA Systems, Inc.
Darren Platt Ping Identity
Nick Ragouzis Enosis Group
Irving Reid Hewlett-Packard Company
David Staggs Veteran's Health Admin
Eric Tiffany IEEE Industry Standards
Greg Whitehead Trustgenix
Thomas Wisniewski Entrust
Emily Xu Sun Microsystems
Non-voting:
Bhavna Bhatnagar Sun Microsystems
Peter Davis NeuStar
Rick Randall Booz Allen Hamilton
Membership Status Changes
Bhavna Bhatnagar Sun Microsystems - Granted TC Membership 9/21/2005
Jean-Paul Buu-Sao CapGemini - Requested membership 9/22/2005
Will Hopkins BEA Systems, Inc - Granted TC Membership 9/23/2005
Steve Anderson BMC Software - Lost Voting status after 9/27/2005 call
John Hughes Individual - Lost Voting status after 9/27/2005 call
Dana Kaufman Forum Systems - Lost Voting status after 9/27/2005 call
Peter Davis NeuStar - Granted Voting status after 9/27/2005 call
John Moehrke GE Healthcare - Requested membership 9/27/2005
Eve L. Maler wrote:
> Philpott, Robert wrote:
>
>> 1. Attendance/call-to-order (Conor still on the hook to do
>> minutes this week).
>>
>> 2. Approve minutes of 13-Sep con-call
>
>
> There is one correction to make. Steve Anderson was going to make a
> list of proposed specs for public review; this AI should have been
> assigned to Rob. Rob has completed this AI. So Rob suggests we
accept
> the minutes with that caveat.
>
>>
>> a. minutes for OASIS SSTC conf call, 2005-09-13, revised
>> attendanceinfo
>>
<http://lists.oasis-open.org/archives/security-services/200509/msg00036.
html>
>>
>>
>> 3. Status of SAML Adoption Subcommittee [Eric, chairs]
>>
>> a. Also see Mary McRae post: FW: [staff-standards] SAML
Adoption
>> SC
>>
<http://lists.oasis-open.org/archives/security-services/200509/msg00031.
html>
>>
>
>
> Merritt: Next week will have an update on setting up the SC.
>
> Rob: Mary sent mail to co-chairs requesting an email stating that the
SC
> charter was adopted etc., so that she can send out an announcement.
> Mary also noted that 3M has asked about a "hello SAML" endpoint, and
> suggested that the SC is a place to deal with this request.
>
> AI: Prateek to send adoption SC details to Mary McRae.
>
> AI: Merritt to follow up on the "hello SAML" request.
>
>>
>> **4. **List discussion: [Eric, Scott, et al] - Transient IDs
and
>> SAML Conformance
>>
<http://lists.oasis-open.org/archives/security-services/200509/msg00027.
html>****
>>
>
>
> Tom W.: To be compliant, you need to implement both persistent and
> transient IDs. He sent email with this interpretation and no one
> complained.
>
> Scott: Has a different perspective on "conformance" than others; sees
it
> as very minimal.
>
> Eric: "Support" to him means if you're a customer and bought a product
> with an expectation of support, it should do something useful. Scott:
> The third possibility is a dummy interface, but in production it does
> nothing useful. Eric: But then there's a place for someone to extend
> the implementation with some kind of plug-in.
>
> Hal: The counter is that the market can take care of the "problem of
no
> functionality". What's harder is interoperability, and that's where
the
> standard comes in. Scott: People are trying to include in the
> definition of "support" stuff that's out of scope of the spec.
>
> Scott: Maybe the open issue is that the conformance spec needs to be
> revised to indicate specific implementation items that aren't part of
> the specs otherwise. Eric: There will always be a need for some
> interpretation. We need to draw a line somewhere.
>
> Scott: In the thread, he corrected the misimpression that SLO has
> anything to do with the type of identifier. Eric: But if you used a
> transient nameID to do SSO, you as the SP should be able to forward
the
> transient ID in an SLO request. Or, if the IdP initiates the logout,
it
> and the SP should still be able to use the transient nameID in SLO
> operations. Rob: We've already said that transient IDs have to live
for
> the life of the session. Eric: So the appropriate standard of
> implementation is probably to show that whatever you can log in with,
> you should be able to log out with.
>
> Rob: Eric's request has come up in the context of Liberty interop
> testing. Do we need to do anything to the SAML specs in response to
the
> request? Tom: Eric was interpreting the SAML conformance spec, so
does
> that spec imply the "right" level of support? If we did another RSA
> conf-type interop, and there was a scenario that needed transient ID
> support, would everyone raise their hands and say "yes"? Rob: I don't
> hear any requests to change spec text.
>
>>
>> **5. ****List discussion: [Jahan, Scott] - HTTP GET in Redirect
>> Binding
>>
<http://lists.oasis-open.org/archives/security-services/200509/msg00032.
html>******
>>
>
>
> Jahan: This was a small, simple issue that was clarified. We can skip
it.
>
>>
>> **6. **saml-dev list discussion: [Mike Beach, Scott] -
>> Compatibility Clarification
>>
<http://lists.oasis-open.org/archives/saml-dev/200509/msg00017.html>****
>
>
> Rob: Mike Beach indicated that his questions were answered by Scott.
> Scott: The confusing point was something in the FAQ. Even though the
> namespace is the same, we changed something in such a way that it
can't
> be described as compatible. Suggests that we change the FAQ to
> eliminate any suggestion of compatibility, even though this overstates
> the situation.
>
> AI: Eve to change the FAQ answer for 1.0-to-1.1 to remove the
suggestion
> of compatibility and to comment on the fact that products that support
> V1.0 also implement V1.1, such that it's a product compatibility issue
> and a partner communication/contract issue to choose one.
>
>>
>> 7. **saml-dev list discussion: [tom W, Scott] - SSO Response
>> when using HTTP-Artifact
>>
<http://lists.oasis-open.org/archives/saml-dev/200509/msg00019.html>**
>
>
> Scott: This may have been an oversight, but the bindings doc doesn't
say
> anything, so we have to live with that. Let's open an erratum to say
> that we give no explicit advice on this.
>
> AI: Scott to open an errata on SSO Response when using HTTP-Artifact.
>
>>
>> 8. Errata: [Jahan]
>>
>> a. Groups - sstc-saml-errata-2.0-draft-16.pdf uploaded
>>
<http://lists.oasis-open.org/archives/security-services/200509/msg00037.
html>
>>
>
>
> PE23 remains active; Nick is supposed to resubmit some text, and he's
> waiting until we finish PE 25.
>
> PE25 remains open. Nick just sent some email on this. It involves
> changes to two matrices and the addition of some sections, all
providing
> metadata conformance details -- where conformance is strictly
optional.
>
> VOTE: Eve: move to accept Nick's text. Nick: seconds. Further
> discussion: none. Accepted by unanimous consent.
>
> AI: Nick to prepare some text for PE 23.
>
> PE28 remains open. Prateek offered a proposal in an email this
morning.
>
> VOTE: Prateek: move to accept. RLBob: seconds. Further discussion:
> none. Accepted by unanimous consent.
>
> PE29 remains open. Prateek offered a proposal in an email this
> morning. Rob: You might have a web SSO assertion that has authn and
> attrib statements, so you'd ask the IdP for the latter, not an authn
> authority. Eve: The names of the "authorities" in the table are
fairly
> old (authz decision authority should be PDP in any case), so an IdP
> could embody multiple authorities. Rob: So maybe the IdP should be in
> table 2.
>
> Prateek: The proposal is to add two rows to table 2 for the two
> features: "request for assertion identifier" and "SAML URI binding".
> They are both optional for the IdP row and N/A for all the rest.
>
> VOTE: Jahan: Move to accept. Darren: seconds. Further discussion:
> none. Accepted by unanimous consent.
>
> PE31: partially open. We are revisiting items 1 and 4 (2 and 3 were
> already settled). These have to do with using formal (capitalized)
> normative language where the intent is such.
>
> VOTE: Greg: move to accept the PE 31 item-1 proposal. Eve: seconds.
> Further discussion: none. Accepted by unanimous consent.
>
> The proposed text for item 4 isn't quite accurate. It's structurally
> impossible to use wildcards, not forbidden. Proposed substitute:
"Note
> that the URI syntax does not support the use of wildcards in such
queries."
>
> VOTE: Jahan: move to accept the proposed wording above for PE31 item
4.
> Eve: seconds. Further discussion: none. Accepted by unanimous
consent.
>
> PE32: open and pending text from Rob.
>
> PE35: came up recently. An example has a URL that is inconsistent; it
> should be changed to a servicer provider URL.
>
> VOTE: Jahan: moves to change the PE35 example. Scott: seconds.
Further
> discussion: none. Accepted by unanimous consent.
>
> PE10: Jahan already has an action for this.
>
> PE7: We were supposed to vote on this on September 13, but didn't (we
> think!).
>
> VOTE: Scott: moves to accept proposed text for PE7. Greg: seconds.
> Further discussion: none. Accepted by unanimous consent.
>
>>
>> 9. Outstanding document edits and potential public review:
>>
>> a. Technical Overview - Rob currently holding the editor token
>
>
> Rob: Promises to have a new draft out to the list in the next week and
> will coordinate with Eve.
>
> Nick: The graphic edits are almost done. Should he send the
in-progress
> version? Yes. Nick and Rob will coordinate offline.
>
>>
>> b. XPath Attribute Profile - Status? Eve - SSTC web page still
>> links to draft-04. Current draft is 06:
>>
>> ** i. **Groups
>> - draft-saml-xpath-attribute-profile-06.pdf
>> (draft-saml-xpath-attribute-profile-06.pdf) uploaded
>>
<http://lists.oasis-open.org/archives/security-services/200508/msg00050.
html>****
>>
>>
>> ii. **According
>> to 30-Aug minutes, draft-06 was approved as a CD (see Minutes for
SSTC
>> 30-Aug con-call {Corrected}
>>
<http://lists.oasis-open.org/archives/security-services/200508/msg00063.
html>).
>> Need to produce CD copy and include in public review bundle below **
>
>
> AI: Eve to update the rev 06 draft to CD status and to update the
> website to point to it.
>
>>
>> 10. CD documents currently proposed for public review:
>>
>> a. Executive Overview
>>
<http://www.oasis-open.org/committees/download.php/13525/sstc-saml-exec-
overview-2.0-cd-01-2col.pdf>
>>
>>
>> b. SAML V1.x metadata specification
>>
<http://www.oasis-open.org/committees/download.php/13254/sstc-saml1x-met
adata-cd-01.pdf>
>>
>>
>> c. SAML metadata extension specification
>>
<http://www.oasis-open.org/committees/download.php/13845/sstc-saml-metad
ata-ext-cd-01.pdf>
>>
>
>
> Eve: It's good to draw the public's attention to our docs, but what
are
> our intentions on progressing the Executive Overview? Rob: It should
> just go to CS, having gotten public comments. Eve: Makes sense.
>
> Eve: Is public review reserved for OASIS Standard-track items? Hal:
No.
> It can be used for anything, though it's required for OS-track items.
> He suggests batching documents rather than doing them one at a time.
>
> Rob: The XPath Attribute Profile should now also be added to the batch
> above. Should we hold up the batch for the Technical Overview? Eve:
> No. If we can do a public review of the TO at any time, let's do that
> but indicate that it's still being worked on.
>
>>
>> 11. AI Review (see below)
>>
>> 12. Any other business?
>>
>> 13. Adjourn
>>
>>
>>
>> Open AI's:
>>
>> *#0180*: Need to update SAML server trust document *Owner*: none
>
>
> No news.
>
>>
>> *#0216*: Formulate some suggested redline text for PE10 for review.
>> *Owner*: Jahan Moreh
>
>
> Still open.
>
>>
>> *#0224*: Re-work X.509 Authn attribute protocol profile to address
>> SSTC comments. *Owner*: Rick Randall
>
>
> Rob has taken this AI. Rick is in contact with their customer to
close
> the issue and this should be closed soon.
>
>>
>> *#0225*: Third-party AuthnRequest use case *Owner*: Scott Cantor
>
>
> Scott has sent mail to the list; it's still open and we'll take it up
at
> the next meeting.
>
>>
>> *#0229*: Suggest support for passing SAML URI Reference to WSS
>> *Owner*: Prateek Mishra
>
>
> Prateek will close it today; he doesn't think there's any issue.
>
>>
>> *#0230*: SAML Conformance SSL/TLS requirements *Owner*: Eric Tiffany
>
>
> Still open.
>
>>
>> *#0231*: SOAP client cert authn and reln to SAML messages *Owner*:
>> Scott Cantor
>
>
> Still open.
>
>>
>> *#0232*: Metadata Structures Feature in Conformance *Owner*: Nick
>> Ragouzis
>
>
> Closed.
>
>>
>> *#0233*: Put together list of potential CD documents that would
>> constitute a Public Review package. *Owner*: Rob Philpott
>
>
> Closed.
>
--
Eve Maler +1 425 947 4522
Technology Director eve.maler @ sun.com
CTO Business Alliances group Sun Microsystems, Inc.
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]