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: 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 

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 

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


> *#0233*: Put together list of potential CD documents that would 
> constitute a Public Review package. *Owner*: Rob Philpott


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]