[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft minutes for 27-Sep SSTC con-call
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-metadata-cd-01.pdf>
>
> c. SAML metadata extension specification
> <http://www.oasis-open.org/committees/download.php/13845/sstc-saml-metadata-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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]