Subject: Minutes for 22-Mar SSTC focus group con-call
I. Status and next steps with SAML 2.0 supporting docs
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.
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?
Prateek – We’ll address it on the official call next week.
[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.
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.