[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes for 22-Mar SSTC focus group con-call
|
Attendees:
I. Status and next steps with SAML 2.0 supporting docs
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. 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. Rob Philpott |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]