[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
|
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:
Thurs - Frederick ---------------------------------------------------------------- Tuesday AM minutes (compliments of John Kemp)
o Changed to inactive
o Changed to inactive
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'.
Eve: Notes difference between active and completed - completed items are basically "feature complete".
*** Follow-up: Update contributor/editor lists
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.
o Scott - should probably ref SAMLBind - this is de-referenceable using that binding. o Eve/Scott discuss referencing between documents.
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.
o Conor - does this impact session established with SAML token? o FJH - this is policy
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.
o Eve - better define the terminology of AuthnContext within that 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.
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.
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)
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.
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).
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.
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.
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.
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.
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?
o Needs editorial work
o Conor: show examples of assertions in document? o Eve: would also be good to show complete use cases in implementation guide.
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
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.
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?
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
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)
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.
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.
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.
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.
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.
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.
o Hal asks what change would satisfy this concern. This has also been discussed in WS-I. *** AI: Fred Hirsch will propose text.
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.
Wednesday PM minutes (compliments of Paul Madsen)
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
o EM - this can't be called a profile o JL - this is the original definition of 'profile'
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. 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
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.
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 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. 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
o seems to be consensus that NotBefore is not particularly useful o 3 Times (to two intervals) o
Time during which: 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
*** 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
Thursday AM minutes (compliments of Frederick Hirsch)
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.
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
*** AI - Scott Determine how Kerberos principals can be represented as NameIdentifiers. 1510 possibility.
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.
o Core 06 - Closed - Assertion level subject- prose based optional subject o Core 15 - closed - health warning on xsi:typeExtensions
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
*** AI: Scott to draft proposal
*** AI: Prateek - will generate list potential changes from core
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.
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
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?
*** AI - Hal to notify XACML
*** AI: Rob to post KAVI polls for next f2f
*** AI Prateek to contact ID-FF vendors
*** AI: JeffH to send query to Liberty members
Rob Philpott
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]