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 17 January 2006 SSTC telecon

AI summary:

(#4a, 4b) Tom W. to send out a suggestion for shoring up the 
conformance language to clear up the requester/responder mismatch.

(#4d) Greg W. to propose some clarifying text for the attribute 
profile section.

(#5a) Jahan to revise the PE 10 wording proposal.

> 1. Attendance

27(+?) of 32 voting members present.

> 2. Approve minutes from December 6, SSTC Conference Call
> http://www.oasis-open.org/archives/security-services/200512/msg00013.html

Approved by general consent.

> 3.  Document Updates
> a. Website Updates
> http://www.oasis-open.org/archives/security-services/200601/msg00008.html

OASIS has dictated a new template to be used for public TC pages. 
All the newest TC documents have been linked from the page.  The 
Adoption SC should update its OASIS public page if it can.  However, 
Merritt Maxim has had to step down from the Adoption SC.

> b.  XPath Attribute Profile
> http://www.oasis-open.org/apps/org/workgroup/security/download.php/16111/sstc-saml-xpath-attribute-profile-cd-01.sxw 

The CD version had to be corrected to fix some of the examples.

> c. SAML 2.0 Constrained Delegation Profile
> http://www.oasis-open.org/apps/org/workgroup/security/download.php/16076/sstc-saml-constrained-delegation-profile-draft-00.pdf 

A rev-00 draft has been produced.  Prateek has received some 
feedback and will produce a revision next week.  Scott noted that 
Conor thinks the document isn't necessary (through a note sent to 
saml-dev), which Scott thinks would be nice but isn't sure it's 
true.  The theory is that, having created a placeholder in the 
syntax for this purpose, it's not clear it can be interpreted in any 
other fashion.  Since you have to include a name ID (and it's 
recommended that you include an audience), maybe we don't need extra 
text.  How interoperable is the current situation with subject 
confirmations -- are they sufficient?

Higher-level delegation semantics are not part of the current specs. 
  Beyond the subject confirmation mechanism, documenting the 
delegation parties and flow is left to the implementation.  Is the 
presence of the subject confirmation inside the assertion enough to 
convey the circumstances of assertion creation, or not?  If a given 
entity uses a particular key, it's treated as the attesting entity 
(metaphysical considerations aside).  If that's enough to 
discriminate that entity from the subject, we don't need the extra 
profile language.

What is the mandatory processing rule for the relying party on 
encountering this?  It is just informational?  The profile attempts 
to set up rules for verification.  It provides tighter 
interpretations for existing constructs.  Is it a "meta-profile"? 
Or would it be best as merely a clarification of the core spec?

> 4. Active Threads
> a. *Authn Query and Authz Decision Query Requesters <msg00000.html>*
> http://www.oasis-open.org/archives/security-services/200601/msg00000.html

The clarification made informally was that you'd have a separate 
notion of a requester for each authority, and Thomas indicates that 
this seems sufficient.  In the conformance spec it talks only about 
generic "requesters" across all sorts of authorities, which is 
perhaps slightly unclear.  What does it mean for an attribute 
authority to respond to an authorization decision requester?  You 
can respond with any sort of statement in your responding assertion, 
but from a WSDL standpoint, the intent is to only send the right 
kind of query to the right kind of responder.

AI: Tom W. to send out a suggestion for shoring up the conformance 
language to clear up the requester/responder mismatch.

> b.  *SAML Authority and Requester Conformance question <msg00003.html>*
> http://www.oasis-open.org/archives/security-services/200601/msg00003.html*

Same as above (#4a).

> c. Extensions and Profiles <msg00009.html>*
> http://www.oasis-open.org/archives/security-services/200601/msg00009.html

The discussion is ongoing in email.

> d. *LDAP Attribute Profile (saml-profiles-saml2.0)
> http://www.oasis-open.org/archives/security-services/200601/msg00013.html

This seems to have settled out.  We may need a couple of errata 
items to ensure that the thread doesn't have to be re-enacted again 

One issue is just an error in the spec example.  Another issue is 
whether the ASN.1 wrapper is intended to handle binary data.  The 
tendency seems to be to avoid having the additional wrapper layer. 
If you include the base64-encoded value directly, using the LDAP 
profile for it doesn't have any particular implication for special 
processing.  Finally, there's a philosophical issue about attribute 
syntax assumptions.  You can't assume anything about the encoding of 
values by looking at the name format; it would be a local deployment 
issue.  Out-of-band agreement will be necessary at some level.

AI: Greg W. to propose some clarifying text for the attribute 
profile section.

> e. **Use of Audience as delegation flag <msg00022.html>*
> *http://www.oasis-open.org/archives/security-services/200601/msg00022.html

This seems to be covered by our discussion above (#4a, 4b).

> 5. Errata Review/Status

There's no new errata document this time.

> a. *Proposed text for PE 10/Action item 0216 <msg00008.html>*
> http://www.oasis-open.org/archives/security-services/200512/msg00008.html

There has been text proposed, at the link above.  Where spec text 
deliberately constrains more than the schema, we've said that the 
spec text takes precedence.  This was an oversight and not 
deliberate, but in fact assuming deliberateness would "work", since 
URIs are subsets of strings -- the schema isn't strictly "in error". 
  It would be worth having an erratum just clarifying that anyURI is 
indeed the right interpretation.

AI: Jahan to revise the PE 10 wording proposal.

> b. *error in saml-profiles-saml2.0 example (section 8.5.6) <msg00015.html>
> http://www.oasis-open.org/archives/security-services/200601/msg00015.html

Noted.  Examples are non-normative, so this is low-criticality.

Prateek brings up a new PE regarding holder of key problems:


Eric Tiffany brings up a new PE regarding metadata:


> 5. Open AIs
> *#0243*: Clean up text in Section (RequestedAuthNContext)
> *Owner*: Scott Cantor
> *Status*: Open
> *Assigned*: 2006-01-17
> *Due*: ---

Scott needs to refresh his memory on the AI before tackling it.

> ------------------------------------------------------------------------
> *#0242*: Recommended text for SAML Attr Sharing Profile
> *Owner*: Rob Philpott
> *Status*: Open
> *Assigned*: 2006-01-17
> *Due*: ---

Still open.

> ------------------------------------------------------------------------
> *#0240*: Status of SAML 2.0 submission to ITU T
> *Owner*: Abbie Barbir
> *Status*: Open
> *Assigned*: 2005-11-07
> *Due*: ---

Abbie has asked Eve for help filling out a form having to do with 
Liberty's PAOS spec, on which SAML depends.  She will probably 
delegate this.

> ------------------------------------------------------------------------
> *#0238*: Plan for red-line versions of SAML 2.0
> *Owner*: Eve Maler
> *Status*: Open
> *Assigned*: 2005-11-07
> *Due*: ---

Still open.

> ------------------------------------------------------------------------
> *#0237*: Interop Test question: Metadata 2.0 EndpointType question
> *Owner*: Eric Tiffany
> *Status*: Open
> *Assigned*: 2005-10-24
> *Due*: ---

This has to do with #5 above; we can close it.

> ------------------------------------------------------------------------
> *#0235*: Various Editorial Changes
> *Owner*: Eve Maler
> *Status*: Open
> *Assigned*: 2005-10-10
> *Due*: ---

This can be closed.

> ------------------------------------------------------------------------
> *#0234*: Nick to prepare some text for PE 23.
> *Owner*: Nick Ragouzis*
> *Status*: Open
> *Assigned*: 2005-10-10
> *Due*: ---

Nick had thought we agreed to drop it for now.  Perhaps we can find 
a new owner.

> ------------------------------------------------------------------------
> *#0230*: SAML Conformance SSL/TLS requirements
> *Owner*: Eric Tiffany
> *Status*: Open
> *Assigned*: 2005-09-12
> *Due*: ---

Eric will try to tackle this soon.

> ------------------------------------------------------------------------
> *#0180*: Need to update SAML server trust document
> *Owner*:
> *Status*: Open
> *Assigned*: 2004-07-12

Still open.

In addition: Scott would like to make progress on the extension 
document.  In fact, there are several documents outstanding that we 
were planning to send to public review in batch form.  Should we 
queue up that vote for the next call?  Scott will consider that.

France Telecom is looking at the extension profile for use against 
some of its current requirements.

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]