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: Minutes for 22-Mar SSTC focus group con-call


  • Prateek M
  • Rob P
  • Rick R
  • Greg W
  • Tom W
  • Alberto S.
  • Paul M
  • Scott C
  • Bob M
  • Jeff H
  • Peter D
  • Eve M


I. Status and next steps with SAML 2.0 supporting docs

  1. http://www.oasis-open.org/apps/org/workgroup/security/download.php/11786/sstc-saml-exec-overview-2.0-draft-06.sxw
    1. List comments:

                                                               i.      http://lists.oasis-open.org/archives/security-services/200503/msg00056.html

                                                             ii.      http://lists.oasis-open.org/archives/security-services/200503/msg00060.html

Prateek: plan is to vote to approve this doc as CD at next call

Scott: meta-question perhaps need to be discussed on next TC call:  How does the TC want to handle supplementary material on a non-standards track that we want to have official status?  There seemed to be issues with the Gross response document.

Rob: Perhaps the issues are different for the Gross document than for these other outreach documents. We just don’t know what those issues were.

Greg W: what about the metadata 1.x document?

Scott: it was approved on the last call.  That’s what made the other objections on the Gross paper strange.

Prateek: we want these documents to have official status. 

Rob: That’s what CD is for.

Paul: (back to exec overview) I’ll be updating and distributing draft-07 by end of week.


  1. http://www.oasis-open.org/apps/org/workgroup/security/download.php/11511/sstc-saml-tech-overview-2.0-draft-03.pdf

Prateek: Without Eve or John on the call, do we wish to comment now?

Scott: Feels there is more work to do on it before it’s ready for a vote.  We need to be careful about text re: federation in later section.  Might not be a quick process to get agreement on it.  We could just drop those sections if we can’t reach consensus.

Prateek: we’ll defer a vote on this one.


II. Any other business?

  1. Scott: Metadata extensions for attribute requesters – want to get this approved so others (e.g. Rick) can refer to it or implement using it.

Prateek – We’ll address it on the official call next week.


  1. Bob M: email re: SIP extensions to SAML.  How should we handle this type of work?

[Rob – I didn’t catch all of this good conversation… if there’s anything important left out or misrepresented, please respond to the list.]

Prateek: At a minimum, we can provide (weak) informational link from our web site to their spec’s.

Jeff: Registration of profiles issue/process.  When it becomes an RFC, we could ask them to send us a note and we keep a pointer to it.  They could join the saml-dev list and have their conversations there.

Rob: Once we move under the new IPR policy, are there issues with them conversing on that list?

Jeff: okay – maybe the discussion should stay on the SIP list if the IPR policy issue is a problem.

Rob: we could simpoly establish an SSTC liaison and that person could provide the information exchange.  If things need more discussion, we could invite them to meetings.

Scott: if they are working on a profile that is not a TC work product, then I assume that identifiers etc wouldn’t be oasis-based.

Peter: agree – they should be in the IETF namespace.

Bob/Jeff/Scott – much discussion of possible processes to deal with this.

Jeff: Looking at the spec – they are proposing some URI’s in the oasis sstc namespace. I believe we have the right to let them do this.

Rob: Not sure – oasis may object if the spec is an ietf work product and not an sstc work product.

Jeff: we could expand the registration process to permit handing out URI’s, etc. Not too different from what we did for IANA MIME type.

Rob: I just want to make sure oasis doesn’t object.

Greg: MIME type registration is a bit different.

Eve: if we think a saml namespace is the right thing for the URI’s, then a shell spec analogous to MIME type registration shell spec could be used.

Greg: in other words we need an official oasis document that describes the process for letting other organizations define urn’s in the oasis namespace.

Jeff: we, the TC, need to decide if its worth doing a registration mechanism.

Eve: 2 main choices: informational reference – then they need to choose their own urn’s not in the oasis/saml namespace. If we want us to sanction the work, then we need a spec to deal with urn allocations.

Peter: we could delegate to ietf a portion of our oasis/saml namespace.

Eve: that would need OASIS staff involved in that decision.

Greg: seems that they should allocate urn’s out of their own space.

Bob: URN allocation is not really the issue.  The real question is whether we have any TC process for them to define their own profile/SAML extensions for SAML/SIP. Is there an ongoing saml extensions sanctioning function for the TC.

Scott: are they proposing general extension techniques that might be generally applicable for SAML?

Rob: We could invite them to attend a future meeting to discuss a plan to proceed.


Scott: Do we have a suggestion on how we might propose allocation of urn’s for something like metadata extensions?

Eve: Need something that allows for “free-floating versions”

Greg: could have “extensions” branch in the urn’s under the saml branch that are independent of version.

Scott: I’ll start a new list thread for this item w.r.t. metadata since we want to get it to a vote. It’s already pretty close to Eve’s proposal.  I don’t like version numbers in them, but we already have them there.

Eve: will get a writeup in response to that thread.


  1. Eve: I updated the FAQ.  Please check it out.


  1. revisiting earlier items with Eve now on the call

Eve: Tech Overview - Let’s get the discussion going on the list – I’ll send my comments.

Eve: What was the issue with not getting CD status to documents like the Gross response document?

Rob: Don’t know.  But Let’s go ahead and link to the doc from the page.

Prateek: I’ll query the list about why this doc wasn’t approved as a CD.


Rob Philpott
Senior Consulting Engineer 
RSA Security Inc.
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]