Minutes for 22-Mar SSTC focus group con-call

Attendees:

 
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

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

 
  
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.

 

 
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?

 
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.

 

 
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.

 

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

 

 
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 

mailto: