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: Consolidated minutes for Austin SSTC F2F #4 from 30-Mar thru 1-Apr

Title: Attendance of Voting Members

Attendance of Voting Members

  Frank Siebenlist Argonne Natl Lab

  Hal Lockhart BEA

  Tim Alsop CyberSafe

  John Hughes Entegrity Solutions

  Paul Madsen Entrust

  Irving Reid HP

  Paula Austel IBM

  Maryann Hondo IBM

  Michael McIntosh IBM

  Anthony Nadalin IBM

  Scott Cantor Individual

  Bob Morgan Individual

  Prateek Mishra Netegrity

  Conor Cahill Netscape/AOL

  Frederick Hirsch Nokia

  John Kemp Nokia

  Charles Knouse Oblix

  Steve Anderson OpenNetwork

  Jim Lien RSA Security

  John Linn RSA Security

  Rob Philpott RSA Security

  Jahan Moreh Sigaba

  Bhavna Bhatnagar Sun

  Jeff Hodges Sun

  Eve Maler Sun

  Mike Beach The Boeing Company

  Greg Whitehead Trustgenix


Attendance of Prospective Members

  Nicholas Sauriol Nortel


Membership Status Changes

  Nicholas Sauriol Nortel - Granted voting status after 3/30/2004 F2F

  Jason Rouault HP - Lost voting status after 3/30/2004 F2F


Action Item Summary and items that need followup:

  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.  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.
  21.  AI: (Frederick?) ECP Section - 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 - 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
  42.  Deferred item: Discuss ITU-T status at upcoming con-call.
  43.  Deferred item: Baseline Attribute Status and Next Steps - sstc-hughes-mishra-baseline-attributes-01 (yet to appear :-)
  44.  Deferred item: Review AI and list and extract dates from owners/close items
  45.  Deferred item: Establish which work items are "complete" and those that need work
  46.  Deffered item: John Kemp - examine authentiation context method


Thurs - Frederick


Tuesday AM minutes (compliments of John Kemp)


  1. Accept minutes of last meeting - no objections, so approved
  2. Review agenda:
    1. Hal would like to add an item to discuss ITU-T
    2. Frederick - add item to discuss WS-SMS, STP
  3. Tony - explains logistics
  4. Eve - review scope document + re-assess W12, W22, W23, W26
    1. Re-assess W12 - attrib retrieval - anyone in favour? No - change to inactive
    2. W22 - assertion caching - anyone in favour? No.

o        Changed to inactive

    1. W23 - security workflow - no-one knows what it is

o        Changed to inactive

    1. W26 - dependency audit

o        Prateek cared once upon a time, and explains

o        Hal mentions use-case of making assertions about an issuer. Enhanced Condition definitions could support this.

o        Changed to 'inactive'.

  1. Review liason activities:
    1. W18 - SASL. Is this critical for 2.0? Kerberos profiles could use this. Discussions ongoing, but maybe not in 2.0 timeframe.
    2. W20 - ebMS - not for 2.0 timeframe.


Eve: Notes difference between active and completed - completed items are basically "feature complete".


  1. Eve walking through core - draft-08-diff
    1. Ref the XMLNS spec. - we hadn't done that before. Mostly editorial change to introduction.
    2. We need to update the contributors vs. the editors. Eve explains difference between the two lists. Add to list of 1.1 contributors. Rob mentions that Karl has given rules on contributors.

*** Follow-up: Update contributor/editor lists

    1. Eve discusses BaseNameIdentifier
    2. Eve reviews EncryptedNameID

o        Scott mentions 0 or more key distribution for Enc NameIDs. Scott also mentions 'recipient' attribute for the key - do we want to make that a MUST?

*** Follow-up: Review at some future point.

    1. AssertionURIReference - new element - should we mention that URN would require "special" resolution? If URL - security token reference to a SAML assertion.

o        Scott - should probably ref SAMLBind - this is de-referenceable using that binding.

o        Eve/Scott discuss referencing between documents.

    1. Eve - re-ordered Issuer
    2. Scott - re-ordered the ds:Signature element on suggestion from JohnH Lighting discussions - lighting fixed. Everything is Illuminated
    3. Subject discussion.

o        Irving wonders whether we're changing too much. Eve mentions the migration document. Scott says it's Irving's fault. Rob + Greg says this is simpler. Conor agrees this makes processing simpler. Eve asks for volunteer to list changes. Scott says he'll write it up. Jeff H will do this!

*** AI: Jeff H will do this! [Ed. I assume that Jeff has the actual AI here]

o        RLBob mentions problem between assertions and statements. There is an implied semantic of a Subject linked to the Assertion - just not syntactically.

    1. DoNotCacheCondition languuge improved by Scott.

o        Conor - does this impact session established with SAML token?

o        FJH - this is policy

    1. SessionIndex - Prateek objects to MUST NOT for globally unique ID.

o        Greg thinks you need normative langauge for this. Mentions use of the AssertionID. Scott mentions use of AssertionID, and then asks Prateek what the use-case is. Prateek wants to generate the same session id for each SP. Conor tries to remember what the use-case.

o        Conclusion: Some (not mutually exclusive) options:

1.    Use AssertionID

2.    Re-write language to be even more specific

o        Greg presents an option to include

*** AI: JohnK to propose text to meet the privacy needs when using specific NameID Format values.

    1. Eve discusses SubjectStatement changes.
    2. Authn Method - TBD at this meeting
    3. Discussion of authentication statement vs. authentication context statement

o        Eve - better define the terminology of AuthnContext within that element.

    1. AttributeDesignator - for further discussion during the meeting. Proposal added as discussed at last F2F.
    2. AuthZDecisionStatement - implemented decision to freeze.
    3. Eve implemented changes regarding the derivation of protocols from Request/Response
    4. Scott - added Extensions element - modeled to be consistent with SOAP header element - i.e. multiple extensions within one Extensions (header) element.

o        Discussion of ##any vs. ##other.

o        Should use ##other.

o        Scott - should we have a wrapper element for extensions?

*** Follow-up: Resolution: change Extension to use ##other

o        Scott: strongly suggests we use a wrapper element for extensions, in order to better be able to better determine the sequence of elements.

o        Eve - explains difference between anyType, any, and anyAttribute

o        Frederick - suggests unified model for schema extensibility (allow anyAttribute on ALL extension elements). Maybe want to add attributes to the Assertion?

o        Scott - argue Ann's question about anyAttribute.

o        Decision: 1) keep wrapper element 2) use ##other for now, and maybe expand scope if we find a good reason.

o        Discussion of extension by extenders.

o        Tony: Provide method of reference extensions. If I have an extension defined, and I want to reference it, how would I do that? Add anyAttribute in useful places.

    1. Discussion of status codes.

o        Scott made a list in one place.

o        Eve wanted to split them out.

o        Rob - we need to have these in both places - should alphabetize in the list, and then refer to them in the protocol/profiles.

o        Rob: Do we have to expose this much information in status responses?

o        Scott: We didn't do anything gratuitously - tradeoff between usability and security

o        Eve mentions use of Qname in StatusCodes for IOP causing problems.

    1. SubjectQuery - SessionIndex - what does it mean that Subject is now at the assertion level? Again we need to think about Subject-less-ness.
    2. Query processing rules (line 1682) text revised for type hierarchy of NameIdentifiers
    3. Scott - revised text about what it means to match SubjectConfirmation?
    4. Scott explains Authentication Request protocol

o        Intent is to write a general protocol that can be profiled for specific uses. There are many complex things that you can do when authenticating. We took the Lib AuthnRequest, and exploded it into fully parameterized assertion request. Profiles would then profile it down.

o        Defined a vocab to capture the players in several scenarios.

o        Hal: Why isn't this possible in current SAML?

o        Scott explains use-case

o        Conor - mentions Liberty use-case of authentication context - SP can control the strength of authentication. Hal + Conor converse.

o        Paul: Policy advertisement mechanism

o        Eve: Not policy.

o        Hal: Requires capabilities not specified.

o        Scott: Authority can't figure this out itself - request should specify input. Scott continues - is this thing an auth authority, a credentials collector? Or what?

o        Conor: Should be a separate discussion item on agenda

o        Eve: Have we become too general?

o        Hal: Need a general framework

o        JeffH: We need to review the profiles well.

o        Eve: Can we make some slides explaining this whole thing better?

o        Scott to try and present this succinctly.


Tuesday PM minutes (compliments of Paula Austel)


  1. Discussion of Artifact Protocol
    1. 3.5.1 ArtifactRequest

o        Scott: deliver a message by value rather than by reference. Protocol should be done in an authenticated manner. This describes protocol for doing dereferencing.

    1. 3.5.2 ArtifactResponse

o        Scott: Old model, sending more than one assertion, multiple artifacts. This change lets you return one artifact tied to the response.

o        Conor: Use case on request: HTTP redirect

o        Scott: before never had request only request/response or response

o        Scott: If you can make an argument for needing an artifact on one side (request or response) than you can make an argument for the other side.

o        Conor: Can see a use case where artifact is only used on one side

o        Scott: Trying to make a general use case and not create special features.

o        Scott: Make passing of messages independent of messages. Try to eliminate Post and Artifact Profiles.

o        Tim: How to handle case where response does not come back?

o        Scott: Not specific to artifact discussion

o        Prateek: Should we sign or authenticate?

o        Scott: Common language on all protocol messages.

o        Prateek: Concerned about text on line 2118 "...SHOULD be signed or otherwise authenticated...."

o        Scott: Not a MUST, need to provide some recommendation to protect message.

o        Eve: this is boiler plate text for all messages. Need to agree on the correct text for this.

***Follow-up: Review/fix boilerplate text re: recommendation for protecting messages

o        RL Bob: Telling people who are writing bindings what they should say

o        Scott: Also message to developers

o        Prateek: does this disallow case when you send message over HTTP

o        Scott: It's a SHOULD (MAY would be too weak)

o        Eve: Would a reference to bindings document help?

o        Scott: In old protocol, signing was not wanted. Needed to authenticate both parties.

o        Eve: #any should be ##any

o        John Kemp: Misleading that "any" is used (not necessarily dangerous)

o        Eve: Need to constrain wild cards (any). Need to add prose to define what is expected.

o        Conor: redirect is better user interface for users on phones (need to consider this use case)

o        Eve: Need to motivate generality

o        Scott: Would need to define artifact processing for 5 profiles.

o        John Linn: First reaction, nice generalization but it's new and scary. Seems to be a natural set of generalization.

o        Prateek: any profile that uses this would have to verify its use.

o        Scott: choice of what to use is deployment specific

o        Prateek: Need to specify what is mandatory to implement. Don't want customers specifying that there are 16 variations in the spec but vendor is only implementing one.

o        Scott: Implementers prefer generality.

o        Eve: what do we say to implementers of 1.x? We have allowed embedding protocol message in a response.

o        Eve: Can't know how we feel about this until we discuss profiles.

o        Scott: Need to change text in bindings to match this.

o        Frederick: Need to go back and ask question about previous section on Authn request line 1628 AssertionConsumerServiceURL - Wording suggests it is used for only an error (this seems too strong). ECP uses URL, not just for errors.

o        Scott: It is used only for errors.

o        Scott: What's written has to be weakened so it's not limited just to errors (can see other uses for this).

    1. 3.5.3 Processing Rules

o        RL Bob: relationship between issuer and signer is more restrictive here - SAML in general says nothing (they can be anything) - For these protocols need some rationality between the relationship of issuer and signer.

o        Irving: Could create a table that shows relationship between issuer and signer.

o        Scott: What to do when you have metadata about signer

o        RL Bob: there will be many policies and need to validate against policies

o        scott: id-ff - tight relationship between metadata, signers and keys

o        Conor: somewhere in the spec there has to be rules for signatures. We could refer that section here.

o        Irving: don't want to be specific here about policy for validating signatures. A profile for id-ff can specify policy for validation.

o        Rob: Can we remove the second sentence? (lines 2136-2138)

o        Scott: We should be able to remove issuer all together

o        Irving: In SAML 1.0 specifically separated signers and issuers.

o        Tony: The first sentence (line 2136) is too strong

*** AI: RL Bob/Irving: Need to change the wording for the first paragraph under section 3.5.3 Processing Rules.

o        Tony: Don't want to have to validate all signatures if more than one

o        Scott: There will only be one (multiple signatures might be possible later)

o        Frederick: Can't you combine signature and TLS and later decide not to validate signature because of transport over secure channel.  

o        Scott: say nothing about signatures in any of the individual protocols. Schema permits signing of messages for protocols that do not provide integrity protection.

    1. 3.6 Federated Name Registration Protocol

o        Prateek: Has anyone deployed this protocol? Concerned that this may be a niche protocol.

o        Conor: From IDP side found this useful for consolidating accounts.

o        Scott: Get rid of restriction in red (line 2176) "Only federated identifiers.......can be replaced and set with this protocol...." Get rid of this text all together.

o        Eve: Have to address notion that we have multiple protocols now.

o        Prateek: How to roll over persistent pseudonyms

o        Prateek: IDP pushes out new proposed identifier, SP pushes proposed identifiers to IDP (more challenging)

o        Conor: Use case SP pushing ID to IDP, providers already have a key that indexes user. Why do they have to use a different key? Have to protect the key so that the IDP does not look at it. Can obfuscate it in any way.

o        Prateek: Still have concerns about implementability and deployability.

o        Eve: Need a conformance document story by next F2F

o        Conor: older systems don't cross domain boundaries but this is changing.

o        Rob: Have to deal with attestations before we go to standards bodies. Need implementations to justify all parts of the specs.

o        Eve: Require 3 or more attestations for use of spec. Conformance document should reflect lines numbers targeted for attestations (implementations).

o        Hal: Not all useful features will be implemented in first versions of products.  

o        Conor: Use case, establish initial connection with social security number and later change the ID to something not connected to ss#

o        Eve: OASIS requires some minimal community wants this and some companies were able to implement. SAML usually has a higher bar than this.

    1. 3.7 Federation Termination Protocol

o        Scott: Name is wrong. "I am no longer going to talk about John anymore"

o        RL Bob: Unregister Name Identifier (to match Register protocol)

o        Scott: Change RegisterNameIdentifier to deregister if no new name identifier is specified.

o        Frederick: Is it good to overload this function? If someone makes a programming error and forgets the name identifier than you deregister and will not discover error until later. Can there be an attribute to specify the intent? Better to be explicit.

*** AI: Scott: propose change to RegisterNameIdentifier to handle unregister case and consider specifying an attribute that identifies intent of operation.

    1. 3.8 Single Logout Protocol

o        John Kemp: No change since last F2F. Only addition was reason attribute. Reason for logout (previously proposed by Hal)

o        Hal: Who is doing logout and why

o        John Kemp: Still have questions on whether you want to specify this information or not.

o        Eve: It's only a string.

o        John Kemp: Should be a URI (mistake)

o        Eve: session index changed to element (not attribute) is this correct?

o        Conor: not attribute of Logout request (maybe this should not be an attribute)

o        John Kemp: this should be an element in this instance (because not an attribute of logout request)

o        Eve: throughout SAML need to examine style of attribute versus element

*** Follow-up: Examine SAML schema for consistent use of XML attributes vs. elements

o        Conor: If SessionIndex is required in assertion request than it should be required here.

o        John Kemp: need to think about whether the above is true or not.

o        Action John Kemp: Review the rational behind SessionIndex

o        Conor: Only time you wouldn't include SessionIndex is if there is no possibility of more than one session.

o        Conor: Can you set an attribute to specify if no SessionIndex than do a logout on all sessions.

o        John Kemp: Need to add a reason attribute on logout request to specify if user's credentials were compromised.

    1. 3.9 Name Identifier Mapping Protocol

o        Scott: Case where Name Identifiers are not globally unique.

o        Conor: RSA was asking for this in Liberty.

o        Prateek: Concerned about deployment and conformance. What is the use case for this?

o        Eve: What profiles use these new protocols?

o        Scott: Do they need to be profiled? Is there another generality that profiling is needed.

o        Eve: Profiles are embodiment of use cases.

o        Scott: Do we need to create profiles to talk about protocols at a conformance level?

o        John Kemp: Need to define relationships between protocols, bindings and profiles.

o        Eve: Issue - what protocols are reflected in profiles?

o        Scott: A lot of work to create "null" profile to hang conformance statements off.

o        Eve: Can several protocols be combined into one profile?

    1. Section 5

o        Needs editorial work

    1. Document in general

o        Conor: show examples of assertions in document?

o        Eve: would also be good to show complete use cases in implementation guide.

    1. Proposed solution for assertion-level subjects (includes Subject-less assertions)

o        Thread begins with http://lists.oasis-open.org/archives/security-services/200403/msg00028.html

o        Scott: Subject may be specified in a way that is not consistent with SAML

o        Hal: XACML policy is SAML wrapper. Policies are for accessing resources (not defined as subjects as in SAML). In XACML refers to system entity. No sensible use for Subject.

o        Conor: specified that subject is implied.

o        Scott: Not legal to have nothing

o        Scott: Lots of queries don't make sense without a subject.

o        Eve: Use framework to make security assertions (with subject-less statements). SAML changed the way subjects are handled which creates an issue for XACML use.

o        Irving: Only profile assertions with subject information for SAML (don't prevent some other group from using it without subjects)

o        Conor: Can specify each statement in SAML requires a subject.

o        Scott: Too hard to create restrictions in schema (subject required for SAML statements). Easier to express this in prose.

o        Scott: don't want to create profiles to show information in core (to show subjects).

o        Hal: XACML wants to do authorization decisions correctly.

o        Rob: SAML is an assertion framework. Others might want to use the assertion framework.

o        Conor: Summary: Ok with subject-less assertion; in SAML we document in prose that subject is required, specified at core level and not profile level.

*** AI: Eve: Optional subject implemented in core spec prose. Schema shows that subject is optional.

o        Eve: Has wanted to create a rationale for some of the decisions made on spec. Decision on subject less statements is a good example of what needs to be documented. Making an explicit design decision that is not really explicit on. By choosing to add prose to core spec we're making a stealth abstract profile (generic design decision) that applies to all explicit profiles.

o        Scott: data model (design) decision to require subjects in all SAML statements.  

o        Frederick: need to understand a clear data model

    1. Encryption

o        http://lists.oasis-open.org/archives/security-services/200403/msg00127.html

o        RL Bob: Do we need to protect a SAML message?

o        Hal: Most common cases are transport security, SOAP security or protecting assertion (encryption)

o        Hal: Deliberately excluded all cases (encrypting any bit). Looked for common cases.

o        Conor: Can you make a statement that if you encrypt one attribute then you will encrypt all attributes?

o        Hal: Might not need to, an attribute might be a password that needs confidentiality.  We can add other entities to be encrypted to the list if there are reasonable use cases.

o        Tim: Does proposal cover integrity protection?

o        Irving: Currently can sign whole assertion; are there use cases to sign parts?

o        Scott: Encrypt content and leave element in tact or encrypt the element and content. Scott specified encryption in a different way than Hal did.

o        Hal: Can use the method that Scott has used.

o        Hal: proposed text assumes a new section addresses all issues with encryption (add after section on signature). Bits of schema explained twice. Text for each section will be different.

o        Eve: Is this really necessary to duplicate schema snippets? In Signature there is one comprehensive example. Would prefer to see a discussion of common aspects of encryption (and not duplicate schema).

o        Scott: Encrypt SAML attribute or SAML attribute value?  (Even though we are not encrypting a lot of that same information on the query).

o        Hal: If query is not encrypted then you are giving information about the response.

o        Hal: would encrypted data be stored in a database?

o        Conor: In IDFF concern about leaking information across pseudonyms.

o        Hal: Summary: agreement to encrypt SAML Attribute Statement. Allow encryption of Assertion Statement, NameIdentifier and Attribute Statement.

*** Follow-up: Need schema and some examples.

o        Tony: Are you only proposing encrypting the whole body? Does their need to be a schema change for use with WSS?

o        Greg: Section 2.1.2 of XML Encryption spec. Describes that if you encrypt an element the attributes on that element are not encrypted. [Small correction per Greg: it's only when encrypting an element's 'contents' that the attributes aren't encrypted.]

o        Irving: Need to make sure anyone who extends statement should inherit the ability to encrypt the statement.

*** AI: Hal: revise proposal to include decisions made here along with details on use cases.

*** AI: Editors: Produce spec text that adheres to proposal for group review.

*** AI: Hal: Look at SOAP binding and make sure hand waving on WS-Security works.


    1. From Small Issues list (see below): DoNotCache - Why?

o        Hal: Way to say validity period once.

o        Eve: could update the spec to show relationship to validity period.

o        Conor: 3 validity times are one issue and single use is another issue.

o        Conor: Need to say this is a one-time use token (and time frames are still valid time frames).

o        Hal: Advisory at best. PDP could look at how it made the decision.

o        Eve: Can we rename this to make it easier to understand use? OneTimeUse?

    1. Discussion on validity period

o        Scott: Binding Condition - carry restrictions / rules based on particular binding. Message validity not assertion validity.

o        Scott: Need 3 things:

1.    Latest time to process assertion in profile (message expiration).

2.    Re-authenticate on or after.

3.    Assertion validity.

o        Rob: May need other conditions besides validity period.

o        Conor: Two time periods, Consumption time period and data content validity. Need 3 time specifications to cover these 2 periods.

o        Rob: Lifetime of use of the data in the statement has to be tied to the statements not the assertion.

o        Conor: Need to add re-authenticate on or after.

o        Scott: Cannot make this a message transmission issue. Need some other indicator (validity on statements), or attaching conditions to statements. Ugliness of doing it at the statement level is overwhelming.

o        Irving: Need tight validity interval to make sure assertion is delivered to relying party in reasonable time.

*** AI: SSTC: Scott made a concrete proposal. Group needs to make comments on proposal.

1.    http://www.oasis-open.org/apps/org/workgroup/security/download.php/6123/sstc-cantor-profiles-draft-01.pdf

    1. List of "small issues" to discuss from white board (collected during the day)

o        Encryption key dist (1 or more) + "recipient"

o        DoNotCache - Why?

o        Privacy Considerations

o        Authn Cntx (stmt, decl, claim,....}?

o        Authn Method?

o        Schema extensibility

o        any Attribute - evil?

o        "SAML Authority == IDP"?

o        Domain Model

o        Consent vs. Reason

o        Element vs. Attribute review

o        QName prefixes in status


Wednesday AM minutes (compliments of John Linn)


  1. Attribute changes (topic leader: Eve Maler), based on attribute-draft-03. 
    1. Changes have been integrated into core-08, Attribute Statements, 2.5.3.
    2. The current proposal has separate Name and NameFormat elements, where NameFormat is a URI (intended to connote both the syntax and semantics of a Name); OIDs and UUIDs, e.g., are now represented with URIs and designated NameFormat values.

o        Scott questions value of NameFormat in achieving uniqueness. 

o        Rob observes a need for source qualifiers to locate particular attributes as stored in different repositories. 

o        There's a sense that the "Source" element is being used, but is currently underspecified, and that conflicting interpretations have been taken. 

o        Conor suggests that attribute sharing should be carried out under a commonly agreed database schema. 

o        Eve observes that the current proposal allows both unitary and qualified names. 

o        Rob comments that the "Source" element would better be placed in the designator, but Scott responds that this would undo many of the properties desired in the changes. 

o        Prateek's needs would be satisfied with a means to annotate attributes. 

o        Following discussion, Scott indicates that he's becoming more comfortable with NameFormat. 

o        Rob would like to avoid a requirement that Names contain URIs, which might need to be parsed (possibly by customer code) before use. 

o        Scott questions whether both NameFormat and Source are needed if they're both likely to be used in the same way, and/or if their usage is unclear.  Among other functions, NameFormat protects against punning in name interpretation if non-URI names may be used. 

o        Scott proposes to add "any" attributes at two levels, and to make NameFormat optional with default to URI; if "unspecified" is desired, that would have to be explicitly specified. 

o        Rob observes that none of his customers are using URI or X.500 attribute names, though others believe that URIs are or should be the common case. 

o        Revisiting discussion, "unspecified" type will become the default, and NameFormat remains as written, but "Source" is removed.

    1. There's been a request from the XACML TC that ValueType for attributes become mandatory, so as to move metadata typing "in-band", but this is contentious in SSTC discussion and SSTC attendees have not identified a need for this. 

o        Irving believes that XACML should apply suitable default typing behavior.

o        RL Bob echoes this argument. 

*** AI: Eve will send a follow-up message to Anne Anderson, which may be possible to discuss at an XACML meeting tomorrow. 

  1. Bindings/profiles review, led by Scott.
    1. Discussion began with bindings-08. 

o        Scott considers that one binds a "protocol" to a "binding" to get a "protocol binding"; in other words, "bindings" in themselves can be protocol-independent and can be applied to arbitrary SAML protocol messages. 

o        It seems confusing to use the word "protocol" without qualification, given that it can apply both to the upper (SAML) layer and the lower (transport) layer. 

o        In the current version, SSL/TLS text has been moved up to distribute across multiple bindings.

    1. The SOAP binding has been updated based on con call discussions. 
    2. Frederick Hirsch discussed revisions regarding generation of SOAP faults, which may not necessarily result in sending of messages; further changes will be made to this text. 

o        Scott suggests that much of the SOAP section's conformance material be moved to other documents.  The PAOS binding refers to the Liberty PAOS specification;

o        Frederick indicates that he's unaware of IPR related to PAOS, and Conor observes that Liberty specifications are subject to reciprocal royalty-free licensing terms.

    1. Scott has added Redirect/POST and Artifact bindings to the document, where Redirect/POST also includes access to elements via the Get method as well as the Post method.  Following discussion, he suggests that these bindings be renamed to "by value" and "by reference"; the bindings' naming will be considered as a follow-up issue. 

o        Scott proceeded to discuss URL encoding alternatives. 

o        John Kemp had provided Liberty-based discussion of the Plain URL Encoding choice, but he and Scott prefer use of the gzip encoding.  Additional constraints (such as Liberty applies) are required in order to maintain the Plain approach as protocols evolve, and this has been problematic. 

o        Scott notes that the gzip approach has performed well, makes signatures easier, and can be optimized by pre-exchange of compression dictionaries.

o        Prateek wants to avoid having multiple encoding methods, and a working consensus in favor of the gzip approach appears to be developing. 

o        Jeff Hodges suggests that implementers' comments be solicited, and Prateek recommends that the chairs send a message to the saml-dev list. 

*** AI: Chairs to solicit comments.

o        In response to implementer requests, Scott has recommended that form-encoded data be carried in XHTML documents to simplify its processing. 

o        Eve expresses concern about making a normative reference to XHTML. 

o        Frederick wonders whether a simpler approach might be possible, and is concerned about the client-side requirements that XHTML usage might imply.

    1. Discussion of HTTP artifact binding;

o        Scott talks through the binding's processing steps. It is described as a composable substitute for the Redirect/POST binding.  A request can be transferred with one binding, and its response returned with the other. 

o        Scott notes that state maintenance is necessary in order to operate in load-balancing environments.

o        Prateek observes that deployment requirements often imply inclusion of various data in URL fields, and that strong prohibitions are therefore inappropriate. 

o        At lines 677-678, messages intended for specific recipients must only be delivered to those authenticated requestors.  

o        An action is needed to propose artifact types; SAML and Liberty have different types, and Liberty's includes metadata. 

o        Prateek believes that convergence on a single type is desirable, and that this should have been done in SAML 1.1;

o        Jeff Hodges agrees with this goal, but Rob sees this as less important. 

o        Liberty's artifact format contains a hash of a provider's identity, which doesn't permit metadata lookup.  Backward compatibility will need to be considered if and as new types are specified. 

*** AI: Jeff Hodges will make a concrete proposal for a common artifact format.

o        Scott describes the URI binding as a specialized case, used for SAML assertion retrieval purposes but not more generally.  Unlike other bindings, it returns an assertion, not a SAML protocol message. 

o        Scott notes that entities other than SAML authorities should be able to construct URIs that reference SAML assertions, and the AssertionID convention with a known assertion request endpoint supports this.

    1. Tony asks a question about Sec. 3.1 (SSL/TLS), noting that some customers may require use of FIPS cipher suites, which apply only to TLS and not to SSL.  He observes that IBM has evaluated FIPS requirements, and has concluded that non-FIPS algorithms must not be included in FIPS-compliant deployments.

o        Hal asks what change would satisfy this concern.   This has also been discussed in WS-I. 

*** AI: Fred Hirsch will propose text. 

    1. At line 175 of bindings, a cipher suite name is missing a WITH.
    2. Tony asks whether reference should be made to the WSS SAML Token profile as an additional binding. 

o        Scott believes that this isn't a binding in the sense being discussed in the SAML binding specification. 

o        Conclusion: a reference will be made, but in the SAML profile document rather than bindings.

  1.  Following the morning's discussion, the agenda for the remainder of the day was revisited, dropping the ITU-T item.  Discussion of the profiles document will move to Wednesday afternoon.


Wednesday PM minutes (compliments of Paul Madsen)


  1. SSO Profile Review
    1. SC - replaces the existing two profiles (POST & artifact).

o        Tried to define an abstract sequence diagram modeling the abstract message exchanges 

o        Six abstract steps

1.    UA access SP

2.    SP determines IDP

3.    SP issues AuthnRequest to IDP, using UA as intermediary

4.    UA authenticates to IDP

5.    IDP issues Response message to SP, through the UA. Message will contain at least an Assertion

6.    SP grants access or not

o        SAML 1.1 starts at Step 5 above

o        Intersite Transfer Service exists for both ends, IDP and SP

o        Single-SignOn Service is where the AuthnRequest (or artifact) gets sent by the UA

o        AssertionConsumer Service is where the AuthnRespone (or artifact) gets sent by UA

o        RelayState should not contain URL

o        PM - concern is that we end up a combinatorial number of combinations of profiles/buildings to be maintained at SP/IDP

o        SC- exists in Liberty. No value judgment, some people believe we need different mechanisms to do the same things

o        PM- in SAML 1.1 we had very definite mechanism

o        SC- not a technical issue,

o        SC-  4 combinations are from 2x2 (by value/by reference and both directions)

o        EM- what is the value of this abstractness

o        SC- important to define what are the requirements at each step

o        CC- this is a good description of what's actually happening

o        EM - does this correspond to 'Destination site'

o        CC- not necessarily, this is me browsing to the SP rather than being sent to the SP from the IDP

o        EM - destination site may be most common but by picking it its no longer abstract

o        JH - there was a gap in SAML 1.1

o        SC - completely encompasses what SAML 1.1 defined

o        EM- so, for conformance, what do you have to support. Is the profile still the unit of conformance?

o        PM - we had two concrete ways of pushing an assertion around,

o        SC - we are both combining the two old profiles and adding new message flows

    1. Protocol Profile - this is where he actually profiles the protocol (the request/response as defined in Core) - it profiles how the protocol can be used within the SSO profile

o        EM - this can't be called a profile

o        JL - this is the original definition of 'profile'

    1. SC - Sections 3.4.1 and 3.4.2 constrain down AuthnRequest and Response

o        For AuthnRequest, the only constraint is that there can't be a Subject. Only relevant if the SP already knew who the User was -as might be possible for reauth

o        PM- don't want to have to build a responder with logic for reauth

o        CC- expectation is that the subject is the same

o        CC - probably not clearly documented what happens if the SP sends a reauth request and the iDP creates an assertion for a different Principal. SP has to know to look at the Subject.
SC - reasonable to allow the SP to indicate the Subject for which an Assertion is being sought
PM - consensus is to remove the 'MUST NOT' and provide guidance prose.

o        TN - can I do these (AuthnRequest and Response) separately?

o        SC- yes, this is conformance question. There is 'source-site first' so you do not need to have an AuthnRquest.

o        CC- this puts a lot more weight on the conformance doc because the conformance doc is going to define what the required flow is.

o        FH - in the previous SAML profiles all the details were there

o        SC- I think you are oversimplifying some of ID-FF.

o        SC- pushing back on the assertion that there are now all sorts of new things to be tightened up in Conformance.

o        CC- If I read this document, I'd assume I have to implement AuthnRequest 3 ways (re-direct, POST, and artifact), and 3 ways for Response.

o        SC- Response Profile more extensive than that for AuthnRequest

o        IR - the restriction that there be only a single AuthenticationStatement is too strict, SC- OK (will change)

*** AI: Scott: Relax AuthenticationStatement Occurrence

o        PM - I'd like to see a line saying that the Response can carry AttributeStatements

o        TN - if there are multiple responders, are they all constrained to meet the conditions?

o        SC- Yes, the AudienceRestrictionCondition names the recipient, which could be a high-level entity

o        RP - it identifies the party for which the assertion was created.

o        BN- is it a change to have a MUST for the AudienceRestrictionCondition/

o        SC- yes

o        BM- are there not two ways to do the same thing now?

o        SC- disagree

    1. Basic Processing Rules (wonkeeee section)

o        SC- disclaimer- you may not like this but what I said was, to try and avoid two signature, the model is to stick everything in the assertion and sign there.

o        PM- proposal is to remove the signature from Response?

o        BM- we are dispensing with the layering model to avoid multiple signatures.

o        CC- SPs have to write code to look for signatures, much better to have one place to look

o        SC- Response serves no role other than a Root element

o        CC- have to put things like CorrelationID where they can be integrity protected

o        FH- so we're moving protocol information into the assertion for performance reasons?

o        HL- so what's the threat, if I don't have sufficient confidence...

o        HL- an assertion means what it means independent of how I got it, worst case is I get a false reject

o        IR- if I make an Artifactrequest and somebody can replay a different Response by playing with the InResponseTo attribute then the Artifact could be associated with another user.

o        SA- collapsing the layers for performance reasons seems very sad

o        CC- I'll take the hit for the performance gain

o        HL- so what else is being moved into the Assertion?

o        SC- .........

o        SC- the point of the BindingCondition is a hack, its everything you would normally put in the Response but can't because it needs to be integrity protected by the signature over the assertion

o        JL- this is not without precedent

o        BM- this is the other direction though

o        BM - move that section 3.6 security Considerations be moved out of document

o        PM- consensus agreement

o        SC- mix and matching between bindings and profiles

o        PM- need an owner to define a limited number of ways to push an assertion from one point to another

o        SC- not just pushing the assertion

o        PM- just because we can do it 3 ways doesn't mean we have to define them as SAML approved. Need to pull their weight. Somebody needs to drive this discussion. So who is going to this?

*** AI: Prateek takes ownership of driving a discussion on limiting combinations.

o        EM- obvious way it to make one of each pair as mandatory to implement

o        SC- I don't want artifact to be the mandatory one

o        PM- we need to discuss this

o        JK- also needs to distinguish between what is mandatory to implement and what is sensible to implement. Shouldn't give people the impression that you can take a piece from here and there and expect things to work

o        EM- sparse matrix needs to be determined.

  1.  Enhanced Client Profile - Frederick Hirsch
    1. General discussion

o        FH- need to determine how to reflect/incorporate Scott's proposal

o        FH- the way that ECP works is that the SP sends an AuthnRequest to the client, and the client knows how to get to the IDP

o        FH- went through doc summarizing recent mods

o        JK- Device should not have to look into the payload to see where the Response should be sent

o        CC- ran into a problem in Liberty, the Response should only be sent to the address specified in the Response, Shouldn't pay any attention to what might have been specified in the AuthnRequest

o        SC- only useful for error responses

o        FH- needs to be renamed

o        JK- might be defined in PAOS, may not have the leeway to rename, must clarify usage

o        FH- also changed messageId, recommended that it be not used, but if used, rersponse must have correlation

*** AI: Section - need to add back SOAP Header to allow an ECP to get info from the SP without having to parse AuthnRequest.

o        SC- should our samples say SAML 2?

o        EM- just saml and samlp, should be version agnostic

o        FH- related to that, are we doing SOAP 1.1 or 1.2?

o        EM- assume SOAP 1.1, on the issue list

o        CC- do we have a standard for namespace prefacing

o        JK- may not have been implemented

o        EM- pretty good

o        FH- changed authnResponse to Response- consistent with everything else

  1.  Validity
    1. FH - what are the requirements?
    2. SC_- I'll try

o        seems to be consensus that NotBefore is not particularly useful

o        3 Times (to two intervals)

o        Time during which:
 - (1) assertion can be accepted/consumed by SP
 - (2) assertion is considered valid

o        Time at which:

 - (3) a session initiated as a result of the profile should be killed or refreshed

o        Scott's interpretation of 1.x is 1 and 2 are the same and extremely short and 3) was unaddressed

o        JL- in X.809 it is 2) that is addressed

o        HL- if you look at the revocation reasons it's clear that X.509 combines 1) and 2), the analogy breaks down

o        CC- my interpretation is that a SAML assertion says that a statement can't be assumed to be valid only at the time - there is nothing in the assertion that would indicate a longer lifetime

o        SC- I think of 1) as having more to do with how its being passed around as opposed to an intrinsic quality of the assertion, and therefore 1) belongs on the Response

o        Consensus opinion was that 1) does belong on Response rather than Assertion.

o        MB- it's the SP that really needs to specify the lifetime policy

o        CC- but the IDP's requirements feed into this decision

o        JL - consider this example, an attribute assertion states that an individual carries the privilege to 'carry our high value transactions'?

o        PM- how long can you depend on the information is the key?

o        CC- validity is not just the length of time

o        SC- is there any sense in which the spec makes it the case that you shouldn't make use of the attributes after a given time? When do I go back and say, 'is this still true'?

o        BM- the mechs that X.509 provides are the CA promises that it will keep track of the information within the cert so that an RP can ask it, and that it will respond to revocation requests.

o        SC- I want to push back on the statement that assertions can't be forwarded, if not there is no point in signing

o        RP - if my assertions gets pushed around within my infrastructure, is that forwarding/

o        ALL- no

o        PM; how do we make progress, what is the plan?

o        RP- carefully define our use cases

o        MB- are we merely redefining names or are there new requirements for time intervals.

o        JK- new requirement is ReauthenticateOnOrAfter

o        Consensus is to add ReauthenticateOnOrAfter

o        GW- there is a use case in the Liberty Web Service world, the SP gets an assertion from the IDP and this assertion can't be short-lived because it needs to be used in subsequent Discovery Requests

o        PM- there is a suggestion that the 'forwarding' use case. a solution is that the issuer of an assertion is free to ignore the time constraints that it placed.

*** AI: (unassigned) - Document the solution proposal by which issuers are not constrained by

*** AI: RL 'Bob' - need text in Core explaining notion of ValidityPeriod is tied to 1) 

*** AI: Scott Cantor - add ReauthenticateOnOrAfter


  1. AuthnContext
    1. JK- proposal is to define a mechanism by which 3rd parties can submit proposed Authentication Context classes
    2. JK- outstanding issue is that we have SAML AuthenticationMethod and we also have Liberty classes that subsume the SAML AuthenticationMethod, desirable to harmonize them
    3. JK - initially thought that SAML AuthenticationMethods were simple and we could do a simple 1-to-1 mapping, not that easy.
    4. JK- asking the group whether or not he should do the mapping?
    5. EM- would changing the AM URIs to classes change the semantic?
    6. JK- probably not
    7. JK- proposal is to stick with existing mechanism and defer the real work to another time
    8. PM- why are we committed to keeping SAML 1.1 AM?
    9. SA- so why not make it a choice?
    10. SC- what worries me are the facilities within AuthnRequest by which an SP can indicate its requirements
    11. SC- parallel issue is should we not be cleaning up the existing SAML 1.1 AMs
    12. SC- asking John Kemp 'do you want to make the schema changes?'

*** AI: On hold - make schema changes so that AM and AuthContext are parallel choices

*** AI: Prateek & Rob - send out message requesting opinions on deprecation of SAML AuthenticationMethod URIs 

    1. EM- confused
    2. JK- happy if the group decides that we should do the single mechanism
    3. EM- the temporary mechanism is to make changes that everywhere one occurs, the other can occur. I'd rather not add infrastructure that it both invasive and temporary.
    4. SC- it will create more work in the next transition
    5. Consensus - John will evaluate work scope and come back with a recommendation


  1. Metadata (Jahan Moreh)
    1. JM- proposal is that we use the Entity terminology rather than iDP/SP
    2. JM- EntityDescriptor is core element
    3. PM- need to clarify relationship between ProviderId and Issuer
    4. JM- entity can act in one of roles, an abstract RoledescriptorType. One concrete type is SSODescriptorType to distinguish between IKDP and SP.
    5. PM- do we still need PDPDescriptor? Given that we are distancing ourselvees from this
    6. SC- not a large amount to worry about
    7. PM- what are the conformance implications?
    8. SC- defines additional roles that are specific to SAML (beyond those defined by Liberty)
    9. SC- completely changed how endpoints are described
    10. JM- Prateek, you had also asked about AttributeConsumerURL to allow a consumer to indicate what attributes a consumer might want
    11. SC- I defined how this would work on the consumer side, not the provider
    12. JM- put together text around Digital signatures; a bunch of different elements can be individually signed. Need guidance on what should be done. Jahan has recommended that all elements be signed individually
    13. GW- desirable to be able to validate one signature over the complete document rather than multiple.
    14. SC- not sure what the use case would be
    15. JM- softter recommendation is that at least one of RoleDescriptor, or EntityDescriptor or EntitiesDescriptor be signed
    16. GW- inclination would be to have a single signature at the top level.
    17. PM- signing model should support the distribution model.
    18. JM- metadata exchange will be accomplished through well know URLs exchanged out of band
    19. SC- subsequent to previous F2F, Neustar has indicated that they would like to see the DNS mechanism (as defined by Liberty) supported.
    20. PM- conformance won't make these required.


Thursday AM minutes (compliments of Frederick Hirsch)


  1.  Kerberos Proposal Resolution
    1. draft-sstc-solution-profile-kerberos-04
    2. Tim Alsop presented a whiteboard overview.

o        picture: [Active Directory]  [workstation with credential store]--[web server with credential store]

o        Two primary use cases discussed, (1) browser and web server with web server determinining identity of user using kerberos (2) work station creating SAML assertion using kerberos on work station. Not necessarily specifically a browser environment.

o        Note that "Windows integrated authentication", or SP-Nego (SP Negotiate) is not a standard, but a specification that was submitted as an IETF draft since expired, but implemented. Mozilla and Apache web server plugins exist.

o        impersonation - authenticate user at work station using Kerberos, cache credentials at web server, then web server can authenticate elsewhere on network using those credentials. This allows end-end authentication in a network.

    1. Greg W - authentication step discussed yesterday, step 4,doesn't require a detailed SSTC specification, since many authentication methods are possible
    2. John H - this could go into the technical overview document to explain how kerberos may be used for authentication
    3. John Hughes presented more detailed scenario.

o        Requirement - pull or push saml assertion to service outside the kerberos domain that produces the original saml assertion.

1.    Authenticate to KDC at active directory

2.    generate assertion using authenticated principal, proprietary implementation, within kerberos domain want to go to remote domain,

3.    AuthnRequest to SAML component within source kerberos domain with secure connection

4.    Get samlp:Response with Artifact or Assertion

    1. Scott - How to use Kerberos with SOAP is undefined, not standard
    2. Frederick - WSS Kerberos Token Profile would be helpful in this area
    3. Scott - could define DCE RPC interface to be SAML protocol, but not done
    4. Tim - trying various approaches, have not worked out solution at this point
    5. Scott - do not use Artifact unless needed.
    6. John H - indicated that there may be a unique issue to this profile regarding how to push assertions, with a potential solution of using a browser  applet to send the assertion from the browser, as opposed to using the HTML form post technique, for example.

*** AI - Scott Determine how Kerberos principals can be represented as NameIdentifiers. 1510 possibility.

    1. Issue of how to support kerberos interaction discussed, possibility of using SAML browser methods but might require knowledge of user agent capabilities, otherwise could use SOAP technique.
    2. Scott - using SOAP makes it easier to address markets.
    3. Tim - Could also put kerberos ticket inside assertion, possible Kerberos confirmation method.
    4. Tim Kerberos ticket lifetime can be passed in AuthnRequest, to address lifetime issues.
    5. Scott - Schema includes Conditions to allow this
    6. Prateek - Part of Kerberos work will be in SAML 2.0, part will be outside SAML 2.0 but enabled by it.
  1. John Hughes - draft 04 of technical overview published this morning
    1. Review/approve SAML V1.1 technical Overview as a Committee Draft (sstc-saml-tech-overview-1[1].1-draft-03)
    2. Changes

o        comments from Frederick incorporated

o        corrections to one of the diagrams

o        restructured: discussion of source site first, destination site first moved since not necessarily part of standard

o        Conor - prefer push, pull

o        Jeff H - SAML 2.0 should carefully define terms so we use SP or IDP, similar source and destination

o        John H - 1.1 technical overview used older terms

o        John H - want to bring document to closure

o        Eve - committee draft is appropriate

o        Prateek - will forward to external parties that had comments on draft

o        Decision: will vote to publish as a committee draft at SSTC meeting in two weeks.

*** AI: Chair action item to send message to list regarding upcoming vote.

  1. Eve leads Issues list discussion
    1. Review issues list (incl prioritized small issues) sstc-saml-2[1].0-issues-draft-07
    2. Draft 08 has not yet been published on site, discussed draft 08.
    3. Closed Items:

o        Core 06 - Closed - Assertion level subject- prose based optional subject

o        Core 15 - closed - health warning on xsi:typeExtensions

    1. priorize high A to lower C, A for today
    2. Open

o        Core-7 -Soap 1.1 vs 1.2 - priority C

1.    Scott - use of SOAP internal to SAML, more of an issue with WSS SAML Token Profile, not in this group

o        Core 8 - open but resolved, so priority C.

1.    Scott has details

o        Core 9 - Eve, Scott priority C

1.    "anyAttribute evil" response to Ann in this category

o        Core 11 - validity period - still open

1.    Scott has short solution proposal, priority A

o        Core 12 - add "for issuer" to item, C

o        Core 13 - pending - resolve by removing restriction

o        core 14 - Ron issue - need input from Ron - B

o        core 16 - new issue, Authentication vs Authn, decision would be helpful for cleanness and elegance. B

o        core 17 - bag of conditions - B

o        core 18 - could make decision today, A

o        Bindings 3 - discuss later - related to conformance, e.g mandatory to implement.  B

o        Tech 1 - terminology as Jeff mentioned, would like to clean up drafts earlier B

o        Tech 2 - at last F2F there was consensus that there are no use cases, A

o        Tech 3 - impersonation - text changes were done for KeyInfo, changes needed for holder of key, Scott may be out of scope.

o        Tech 4 - glossary additions - need to define binding, profile,

*** AI: Jeff H - define binding and profiles

o        "atomic unit of interoperability" proposed

o        Prateek - would like to change definition federation, email thread.

o        Federation Definition - B


  1. Issues added during F2F
    1. Domain Model, "SAML Authority" == "IDP", same as Tech 1
    2. Consent vs Reason - B
    3. Element vs Attribute Review - AuthenticationMethod, SessionIndex are examples, C
    4. QName prefixes in Status - interop issue, new issue to add to issues list, "Replace QNames for Status with URIs", B
    5. Scott's "Binding conditions"

*** AI: Scott to draft proposal

    1. Encryption key (1 or more)  distribution and recipient  A
    2. Privacy considerations?
    3. Jeff H - We need to highlight privacy considerations related to core, could be notes in core, could be section.

*** AI: Prateek - will generate list potential changes from core

    1. Rename Authentication context statement A
    2. AuthnMethod? decided, Scott and John K have action associated with that.
    3. Schema extensibility - already issue Core-9
    4. anyAttribute - evil? - already issue Core-9


  1. Issue List Detailed Discussion of A items
    1. Core-11  Scott described issue.

o        Conor - encryption does not impact validity, just used for confidentiality only while passing third party

o        Scott not with name identifier mapping, can be passed around, if not in assertion can be used.

o        Hal - needs to be in an assertion. Why not have assertion with just name identifier in it, make statement optional

o        Proposal - subject-less assertion with no statements. :)

o        Can change federation time frame by changing name in protocol

o        Prateek - potential issue, how to define the lifetime of a federation, possibly the federation identifier

o        Greg - two lifetimes: 1-time, only for this session, or otherwise indefinite time

o        Scott Exchanging encrypted references to principals - could hand out permanent identifier that should not have one.

o        Conor - NameIdentifier response includes assertion

o        encrypt name identifier - either name identifier or assertion containing name identifier

o        Prateek  All federated identifier establishment contain time period

o        Tony - hard to manage if mandated

o        Conor - dont want to mandate use of assertion, want to simplify at SPs

o        Eve suggests focus group call on the topic.

o        Conor could change name of Reauthenticate On or after to Renew On or After...

o        Hal - relying party decision, offering guidance

o        New issue : lifetime for federated identifiers

o        Eve updated issues list.

    1. core 18 KeyInfo or SubjectConfirmationData

o        Scott - should be choice

o        Prateek -some wanted both

o        Scott could put KeyInfo inside SubjectConfirmationData

o        Eve would require explanation

o        Prateek - biometric in SubjectConfirmationData, key in KeyInfo

o        Eve - decision to make choice group

o        Mike - what is difference in meaning for KeyInfo at top versus KeyInfo inside SubjectConfirmationData

o        Eve - no, just a syntactic

o        discussion ensues, decision to remove KeyInfo

o        Prateek - eliminating holder of key, Ron will have comments

o        Decision - remove KeyInfo, allow within SubjectConfirmationData

*** AI - Eve to implement decision on core 18 after checking with Ron

    1. Bind-3

o        Scott draws table see PDF sstc-f2f-sso-table.pdf. Proposed refers to Scotts refactoring presented yesterday.

o        Concern about number of table entries, complexity.

o        Need for different entries to meet different requirements discussed.

o        Conor - FORM POST needed for SPs that do not use SOAP call.

o        Scott - feels different about Artifact vs POST

o        Hal - proposes implementation guidelines on when to use each cell, depending on requirements.

o        JeffH - wide range of deployment scenarios.

o        Scott - metadata Endpoint = binding, location, location

1.    element name corresponds to message in table

2.    binding refers to binding column

o        Prateek - As editor of conformance draft will start working on draft.  Would like to see Federation identifier establishment and management factored out separately from single sign on functionality. Will raise issue of whether both will be required for conformance to SAML 2 - issue for later discussion.

o        Scott - really wants to see destination site first supported

o        Hal - suggests packages

o        JeffH - what does SAML 2 mean?


  1. Hal gives summary of XACML meeting regarding SSTC.
    1. Next step: propose agenda item on next SSTC focus call on relevant topics related to type information.
    2. XACML members interested in topic to attend SSTC focus call.
    3. Plan for next Tuesday

*** AI - Hal to notify XACML

    1. Prateek requests email from XACML on mail list before meeting.
    2. Discussion deferred until Tuesday.


  1. Review/establish schedule for remaining work and next F2F
    1. Discussed possible additional F2F, end of May beginning of June. Rob to arrange call.
    2. Eve - Plan committee draft vote by end of June to start 30 day public review. Might get enough comments to require a second committee draft.
    3. Eve - should get additional review earlier, drafts are public.
    4. Scott - once a round of changes are in we can have drafts for early review
    5. Candidate committee draft for final comments within TC, last call, end April 30. - include OASIS news notice
    6. F2F mid-May to mid-June

*** AI: Rob to post KAVI polls for next f2f

    1. CD + 30 day public review, end-June
    2. Collect attestations: now to Aug 15

*** AI Prateek to contact ID-FF vendors

    1. OS Balloting request Aug 15
    2. Conor - suggests contacting Liberty vendors that have certified 1.1 Liberty conformance.

*** AI: JeffH to send query to Liberty members

    1. Eve - last call must include delta document, 1 page technical overview
    2. Burton Catalyst is mid-July, July 21-23, possible outreach


  1. Eve - motion to thank Tony and IBM for hosting, much appreciated hospitality.
    1. Motion passed without objection.


  1. Meeting Adjorned.

Rob Philpott
Senior Consulting Engineer 
RSA Security Inc.
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]