[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes for Telecon, Tuesday 13 April 2004
Minutes for SSTC Telecon, Tuesday 13 April 2004
Dial in info: +1 865 673 6950 #351-8396
Minutes taken by Steve Anderson
======================================================================
Summary
======================================================================
Votes:
- Minutes from 3/30/2004 - 4/1/2004 F2F accepted
New Action Items:
- Greg to ensure that readily available GZIP implementations
can conform to our description in bindings
- Scott to implement SSO validity from proposal into
next draft
- Eve to ask Bhavna to post motivation for moving Signature to
front
======================================================================
Raw Notes
======================================================================
>
> Agenda:
>
> 1. Roll call
>
- Attendance attached to bottom of these minutes
- Quorum achieved
>
> 2. Accept minutes from previous meeting, 30 March - 1 April
> < http://lists.oasis-open.org/archives/security-services/
> 200404/msg00020.html >
>
- [VOTE] unanimous consent, accepted
- Irving: Next F2F
- if it will be here, need to know soon
- Rob: has pending action to put up poll for date/location
- have offers for Toronto & Wash
- first poll will narrow location
- Eve: suggests combining date & location
- Hal: ballots can now have variable number of answers
- Rob: will work on this
>
> 3. Review recent document updates
>
> < http://www.oasis-open.org/apps/org/workgroup/security/
> download.php/6347/sstc-saml-core-2.0-draft-10-diff.pdf >
>
- Eve: people should also look at 09-diff, which is new since the F2F
< http://www.oasis-open.org/apps/org/workgroup/security/
download.php/6323 >
- line 506
- moved Signature upwards
- Bhavna sent msg to list asking to move Signature all the way up
- will add to issues list
- [...]
- moving on to 10-diff
- line 529-534
- Scott: factored in support for subject-less assertions
- by schema, could have assertion with no subject and no stmt
- subsections for each stmt describe use of subject
- line 588 is the moving of this section
- line 669 NotBefore and NotOnOrAfter
- line 700 using a NameIdentifier in Audience
- line 869 starts AuthnContext, not really done yet
- Eve: JohnK, are we ready to switch to AuthnContext?
- JohnK: sees approach, but can't begin real work on it yet
- hopes to have good portion done before next F2F
- Scott: changes on page 23 are another case of prose that isn't
enforced by XSD
- line 1243 RelayState moved to bindings
- [...]
- Scott: new (c) issue: what do I do with a Windows principal name?
- Eve: are we at a point to vote saying "this is a suitable working
draft"?
- RLBob: seems a bit early
- Eve: ok, should be gearing up for that soon
>
> < http://www.oasis-open.org/apps/org/workgroup/security/
> download.php/6324/sstc-saml-bindings-2.0-draft-09-diff.pdf >
>
- [ACTION]: Greg to ensure that readily available GZIP implementations
can conform to our description in bindings
>
> < http://www.oasis-open.org/apps/org/workgroup/security/
> download.php/6289/sstc-saml-profiles-2.0-draft-05-diff.pdf >
>
-
>
> 4. Refine recent proposals into proposed text
>
> (a) separate SSO-validity from overall assertion validity
>
> < http://lists.oasis-open.org/archives/security-services/
> 200404/msg00012.html >
>
> Followup proposal from:
>
> < http://lists.oasis-open.org/archives/security-services/
> 200404/msg00014.html >
>
> "So my idea would be to define a set of attributes in
> SubjectConfirmationData when the method is bearer. Among
> them would be NotOnOrAfter and probably any other stuff
> that needed to be signed as part of profiles that use this
> confirmation method."
>
- Scott's follow up is to add SSO validity data to SubjectConfirmationData
when method is Bearer
- seems like the place to define it would be Profile
- it would be in the assertion, and therefore signed
- RLBob: there was a thread about statement-level conditions
- makes me nervous
- Scott: this wouldn't be statement level
- [...]
- [ACTION] Scott to implement SSO validity from proposal into
next draft
>
> (b) XACML TC Recommendations for <saml:AttributeDesignator>
> "metadata"
>
> < http://lists.oasis-open.org/archives/security-services/
> 200404/msg00019.html >
>
- Anne: emailed recommendation
< http://lists.oasis-open.org/archives/security-services/
200404/msg00019.html >
- couple of comments
- there was a question about pulling metadata into separate element,
and whether there would be an impact XACML -- it won't
- there was a question about having only one type for each attr --
won't affect XACML
- Want single, unique component to identify an attr
- Prateek: at F2F, was discussion around single attribute
designator
- Eve: sent email responding to Anne's latest requests
< http://lists.oasis-open.org/archives/security-services/
200404/msg00050.html >
- believes that this request is already satisfied
- Anne: not clear whether NameFormat is used to 'unique-ify' the name
- Eve: NameFormat indicates how to process the Name value, e.g. as
a URI
- Scott: there is no requirement to use the URI NameFormat
- there is no goal to unambiguously map attrs to XACML
- Anne: just wants to make mapping as easy and deterministic as
possible
- Scott: then would be very easy to write profile stating that URI-
based Names are required
- Anne: also trying to make it easy where an XACML profile isn't
followed
- Scott: in that case, there is no requirement in SAML for
uniqueness, so may not be feasible
- [...]
- Eve: SAML today provides adequate infrastructure to support this
- Anne: want datatype metadata to be required
- there are cases where values aren't available yet
- don't expect to get SSTC approval, so moving on to next point
- Anne: if metadata not required, at least define optional element
- more interoperable than leaving up to external profiles
- costs little to SAML spec, seems well-defined
- RLBob: conclusion at F2F was that people that are interested
in such use cases, they would follow an XACML profile where such
an attr would be defined
- Eve: recalls that it was removed was because it was confusing with
XSD means of typing
- however, XSD method seems little-used
- Scott: concerned more on the query side
- Eve: does have some language now to cover that
- Prateek: doesn't this fall into attribute profiling?
- Anne: but different attr profiles can define diff XML means of
expressing this
- Prateek: each profile can choose to omit the core-defined XML
- [...]
- Anne: concerned about conflicting definitions in different
profiles
- Eve: but these profiles will be defining namespace-qualified
constructs, e.g. "xacml:datatype", so there won't be a conflict
- Hal: doesn't think this should be characterized as an XACML
requirement, because people will sooner or later need this
datatype metadata
- Prateek: should we have a group go off and settle this?
- [...]
- Prateek: doesn't want to add this sort of thing without
doing it 'completely', a la an attribute profile or family
- Scott: proposed an approach at F2F that some felt was too
dynamic
- Eve: suggests adding this to the issues list, in category (b)
or (c)
- will put Hal as issue owner
- Rob: can put this on agenda for focus group
>
> (c) Discussion on Kerberos issues. Several messages have been
> exchanged. Do we have resolution? I couldn't find a summary
> message.
>
- Scott: summarizes issue
- What does Kerberos authnMethod mean? Does browser sending pwd to
web server, which in turn performs Kerb login, qualify?
- was this clarified back before my involvement?
- no
- Rob: continue discussion on thread
>
> (d) Following discussion at the F2F, there is now a "Attribute
> Profiles for SAML 2.0" document. This provides a general
> framework for defining varied attribute profiles, such as those
> based on X.500/LDAP syntax or GUID.
>
> < http://www.oasis-open.org/apps/org/workgroup/security/
> download.php/6344/sstc-hughes-mishra-baseline-attributes-03.pdf >
>
> Should this remain a "non-normative" document? Should it not be
> viewed as an additional profile document?
>
- Prateek and JohnH dropped off
- will defer to next focus call
- RLBob: question of "is this an FYI doc?" seems odd
- profiles aren't mandatory to support
- seems that this doc should have profile-type force
- Eve: seems more like guidelines
- would it be wrong for people to use SAML in a way that doesn't
follow these guidelines?
- Hal: depends on what they claim, e.g. SAML 'based', etc
- RLBob: but we allow construction of your own name formats, etc
- [suspended discussion]
>
> (e) Request to change signature ordinality in Assertion/
> Request/Response
>
> < http://lists.oasis-open.org/archives/security-services/
> 200404/msg00028.html >
>
- Eve: hasn't done this, given F2F discussion that Signature go after
Issuer
- Rob: doesn't have strong opinion
- Scott: didn't understand motivation, why is it easier to process at
the top?
- Eve: order has come up in WSS
- [ACTION] Eve to ask Bhavna to post motivation for moving Signature to
front
>
> 5. Deferred items from F2F
>
> (a) Hal to summarize SAML ITU-T status
>
- one question of interest that was raised was about ASN.1 folks joining
TC to define rendering in ASN.1
- real savings comes in schema-aware version
- description published in draft form
- would be attractive to environments with restricted bandwidth or
storage
- other point was that sometime after SAML 2.0 is finished, we should
submit it
- Rob: is this ASN.1 stuff expected to be part of 2.0?
- Hal: no
>
> (b) Deferred item: Review AI and list and extract dates from
> owners/close items
>
>
> (c) Deferred item: Establish which work items are "complete"
> and those that need work
>
>
> (d) Defferred item: John Kemp - ??examine authentication context
> method??
>
>
> (e) Any others that require airtime?
>
>
> 6. Action Items from F2F (clarify owners and timeline if needed,
> I will enter them into the AI repository after the call)
>
> 1. AI: Jeff H (or Scott?): Write up info for migration document
> describing Subject changes
>
>
> 2. AI: JohnK to propose text to meet the privacy needs when using
> specific NameID Format values.
>
>
> 3. AI: All doc editors: We need to update the contributors vs. the
> editors
>
>
> 4. Review at some future point: EncryptedNameID recipient attribute
>
>
> 5. Resolution: Extensions element - change Extension to use ##other
>
>
> 6. AI: Artifact Protocol: Review/fix boilerplate text re:
> recommendation for protecting messages
>
>
> 7. AI: RL Bob/Irving: Need to change the wording for the first
> paragraph under section 3.5.3 Processing Rules.
>
>
> 8. AI: Scott: propose change to RegisterNameIdentifier to handle
> unregister case and consider specifying an attribute that identifies
> intent of operation.
>
>
> 9. Follow-up: Examine SAML schema for consistent use of XML
> attributes vs. elements
>
>
> 10. AI: Eve: Optional subject implemented in core spec prose.
> Schema shows that subject is optional.
>
>
> 11. AI: Hal, Scott?- Follow-up: Need schema and some examples for
> use of encryption.
>
>
> 12. AI: Hal: revise proposal to include decisions made re:
> encryption along with details on use cases.
>
>
> 13. AI: Editors: Produce spec text that adheres to encryption
> proposal for group review.
>
>
> 14. AI: Hal: Look at SOAP binding and make sure hand waving on
> WS-Security works.
>
>
> 15. AI: Eve will send a follow-up message to Anne Anderson, which
> may be possible to discuss at an XACML meeting tomorrow. (This AI
> has already been completed)
>
>
> 16. AI: Chairs to solicit comments on use of gzip encoding for URL
> encoding
>
>
> 17. AI: Jeff Hodges will make a concrete proposal for a common
> artifact format.
>
>
> 18. AI: Fred Hirsch will propose text re: FIPS cipher suites.
>
>
> 19. AI: Scott: Relax AuthenticationStatement Occurrence
>
>
> 20. AI: Prateek takes ownership of driving a discussion on limiting
> combinations of bindings in conformance document.
>
>
> 21. AI: (Frederick?) ECP Section 3.3.4.1 - need to add back SOAP
> Header to allow an ECP to get info from the SP without having to
> parse AuthnRequest.
>
>
> 22. AI: (unassigned) - re: Validity - Document the solution proposal
> by which issuers are not constrained by
>
>
> 23. AI: RL 'Bob' - need text in Core explaining notion of
> ValidityPeriod is tied to 1)
>
>
> 24. AI: Scott Cantor - re: validity - add ReauthenticateOnOrAfter
>
>
> 25 AI: On hold (John Kemp) - make schema changes so that AM and
> AuthContext are parallel choices
>
>
> 26. AI: Prateek & Rob - send out message requesting opinions on
> deprecation of SAML AuthenticationMethod URIs
>
>
> 27. AI: Scott - Determine how Kerberos principals can be represented
> as NameIdentifiers.
>
>
> 28. AI: Prateek - forward Technical Overview 1.1 to external parties
> that had comments on draft
>
>
> 29. AI: Chairs - publish message to list asking for review of
> technical overview 1.1 and indicate that vote to bring to committee
> draft will be at SSTC meeting in two weeks from this week.
>
>
> 30. AI: Jeff H - to propose glossary definition for binding and
> profile, issue TECH-4
>
>
> 31. AI: Scott - "Binding conditions" proposal
>
>
> 32. AI: Prateek - to review core for locations where privacy
> considerations are implicit
>
>
> 33. AI: Eve - implement decision on core 18 after checking with Ron
>
>
> 34. AI: Hal - to send focus call information to XACML list regarding
> SSTC focus call
>
>
> 35. AI: Rob - put Kavi polls for location and dates for next F2F
>
>
> 36. AI: Prateek - to put out notice to saml-dev, id-ff vendors and
> others for saml2 related implementation experience, now, give early
> notice regarding later attestations.
>
>
> 37. AI: JeffH - send notice to Liberty members requesting interest
> in creating SSTC implementations from parties that have met Liberty
> 1.1 conformance tests
>
>
> 38. AI: Eve - publish tentative schedule on home page
>
>
> 39. AI: Eve to publish core-09 by Tuesday
>
>
> 40. AI: Frederick to send his updates on bindings and profile to
> Scott who will then incorporate additional edits.
>
>
> 41. AI: John H - draft of technical 1 pager with final deadine end
> of April
>
>
> 7. Any other business
>
-
>
> 8. Adjourn
>
- Adjourned
----------------------------------------------------------------------
Attendance of Voting Members:
Hal Lockhart BEA
Gavenraj Sodhi Computer Associates
Tim Alsop CyberSafe
John Hughes Entegrity Solutions
Paul Madsen Entrust
Miguel Pallares Ericsson
Irving Reid HP
Paula Austel IBM
Maryann Hondo IBM
Michael McIntosh IBM
Anthony Nadalin IBM
Scott Cantor Individual
Bob Morgan Individual
Prateek Mishra Netegrity
Frederick Hirsch Nokia
John Kemp Nokia
Nicholas Sauriol Nortel
Charles Knouse Oblix
Steve Anderson OpenNetwork
Darren Platt Ping Identity
Jim Lien RSA Security
Rob Philpott RSA Security
Dipak Chopra SAP
Jahan Moreh Sigaba
Bhavna Bhatnagar Sun
Eve Maler Sun
Ron Monzillo Sun
Mike Beach The Boeing Company
Greg Whitehead Trustgenix
Attendance of Observers or Prospective Members:
Dana Kaufman Forum Systems
Jason Rouault HP
Tim Moses Entrust
Anne Anderson Sun
Membership Status Changes:
Dana Kaufman Forum Systems - Requested membership 4/9/2004
Jason Rouault HP - Requested membership 4/13/2004
Rick Randal Booz Allen Hamilton - Lost voting status after 4/13/2004 call
--
Steve Anderson
OpenNetwork
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]