[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
List of "small issues" to discuss from white board (collected during the day) Encryption key dist (1 or more) + "recipient" DoNotCache - Why? Privacy Considerations Authn Cntx (stmt, decl, claim,....}? Authn Method? Schema extensibility any Attribute - evil? "SAML Authority == IDP"? Domain Model Consent vs Reason Element vs Attribute review QName prefixes in status Session closed at 5:15 --=_alternative 007FD2EB85256E67_= Content-Type: text/html; charset="US-ASCII" <br><font size=2><tt><b>Review/approve core draft-04 thru draft-08 changes continued (from morning session)</b></tt></font> <br> <br><font size=2><tt>Eve has published sstc-saml-core-2[1].0-draft-08-diff-from-04</tt></font> <br><font size=2><tt><b> </b></tt></font> <br><font size=2><tt><b>3.5 Artifact Protocol</b></tt></font> <br> <br><font size=2><tt><b>3.5.1 ArtifactRequest</b></tt></font> <br><font size=2><tt>Scott: deliver a message by value rather than by reference. </tt></font> <br><font size=2><tt>Protocol should be done in an authenticated manner. </tt></font> <br><font size=2><tt>This describes protocol for doing dereferencing. </tt></font> <br><font size=2><tt><b>3.5.2 ArtifactResponse</b></tt></font> <br><font size=2><tt>Scott: Old model, sending more than one assertion, multiple artifacts. This change lets you return one artifact tied to the response. <br> Conor: Use case on request: HTTP redirect </tt></font> <br> <br><font size=2><tt>Scott: before never had request only request/response or response</tt></font> <br><font size=2><tt>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.</tt></font> <br><font size=2><tt>Conor: Can see a use case where artifact is only used on one side</tt></font> <br><font size=2><tt>Scott: Trying to make a general use case and not create special features. </tt></font> <br><font size=2><tt>Scott: Make passing of messages independent of messages. Try to eliminate Post and Artifact Profiles. </tt></font> <br><font size=2><tt>Tim: How to handle case where response does not come back?</tt></font> <br><font size=2><tt>Scott: Not specific to artifact discussion</tt></font> <br><font size=2><tt> </tt></font> <br><font size=2><tt>Prateek: Should we sign or authenticate?</tt></font> <br><font size=2><tt>Scott: Common language on all protocol messages.</tt></font> <br><font size=2><tt>Prateek: Concerned about text on line 2118 "...SHOULD be signed or otherwise authenticated...."</tt></font> <br><font size=2><tt>Scott: Not a MUST, need to provide some recommendation to protect message. </tt></font> <br><font size=2><tt>Eve: this is boiler plate text for all messages. Need to agree on the correct text for this. </tt></font> <br><font size=2><tt>RL Bob: Telling people who are writing bindings what they should say</tt></font> <br><font size=2><tt>Scott: Also message to developers</tt></font> <br><font size=2><tt>Prateek: does this disallow case when you send message over HTTP</tt></font> <br><font size=2><tt>Scott: It's a SHOULD (MAY would be too weak)</tt></font> <br><font size=2><tt>Eve: Would a reference to bindings document help?</tt></font> <br><font size=2><tt>Scott: In old protocol, signing was not wanted. Needed to authenticate both parties.</tt></font> <br><font size=2><tt>Eve: #any should be ##any</tt></font> <br><font size=2><tt>John Kemp: Misleading that "any" is used (not necessarily dangerous)</tt></font> <br><font size=2><tt>Eve: Need to constrain wild cards (any). Need to add prose to define what is expected. </tt></font> <br><font size=2><tt>Conor: redirect is better user interface for users on phones (need to consider this use case)</tt></font> <br><font size=2><tt>Eve: Need to motivate generality</tt></font> <br><font size=2><tt>Scott: Would need to define artifact processing for 5 profiles. </tt></font> <br><font size=2><tt>John Linn: First reaction, nice generalization but it's new and scary. Seems to be a natural set of generalization.</tt></font> <br><font size=2><tt>Prateek: any profile that uses this would have to verify its use. </tt></font> <br><font size=2><tt>Scott: choice of what to use is deployment specific</tt></font> <br><font size=2><tt>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. </tt></font> <br><font size=2><tt>Scott: Implementers prefer generality.</tt></font> <br><font size=2><tt>Eve: what do we say to implementers of 1.x? We have allowed imbedding protocol message in a response.</tt></font> <br><font size=2><tt>Eve: Can't know how we feel about this until we discuss profiles.</tt></font> <br><font size=2><tt>Scott: Need to change text in bindings to match this.</tt></font> <br> <br> <br><font size=2><tt>Frederick: Need to go back and ask question about previous section on Authn request</tt></font> <br><font size=2><tt>line 1628</tt></font> <br><font size=2><tt>AssertionConsumerServiceURL</tt></font> <br><font size=2><tt>Wording suggests it is used for only an error (this seems too strong). </tt></font> <br><font size=2><tt>ECP uses URL, not just for errors.<br> Scott: It is used only for errors.</tt></font> <br><font size=2><tt>Scott: What's written has to be weaken so it's not limited just to errors (can see other uses for this). </tt></font> <br> <br><font size=2><tt><b>3.5.3 Processing Rules</b></tt></font> <br><font size=2><tt>RL Bob: relationship between issuer and signer is more restrictive here</tt></font> <br><font size=2><tt>SAML in general says nothing (they can be anything)</tt></font> <br><font size=2><tt>For these protocols need some rationality between the relationship of issuer and signer. </tt></font> <br><font size=2><tt>Irving: Could create a table that shows relationship between issuer and signer. </tt></font> <br><font size=2><tt>Scott: What to do when you have metadata about signer</tt></font> <br><font size=2><tt>RL Bob: there will be many policies and need to validate against policies</tt></font> <br><font size=2><tt>scott: idff - tight relationship between metatdata, signers and keys</tt></font> <br><font size=2><tt>Conor: somewhere in the spec there has to be rules for signatures. We could refer that section here. </tt></font> <br><font size=2><tt>Irving: don't want to be specific here about policy for validating signatures. A profile for idff can specify policy for validation. </tt></font> <br><font size=2><tt>Rob: Can we remove the second sentence? (lines 2136-2138)</tt></font> <br><font size=2><tt>Scott: We should be able to remove issuer all together</tt></font> <br><font size=2><tt>Irving: In SAML 1.0 specifically separated signers and issuers. </tt></font> <br><font size=2><tt>Tony: The first sentence (line 2136) is too strong</tt></font> <br><font size=2><tt>ACTION for RL Bob/Irving: Need to change the wording for the first paragraph under section 3.5.3 Processing Rules.</tt></font> <br><font size=2><tt>Tony: Don't want to have to validate all signatures if more than one</tt></font> <br><font size=2><tt>Scott: There will only be one (multiple signatures might be possible later)</tt></font> <br><font size=2><tt>Frederick: Can't you combine signature and TLS and later decide not to validate signature because of transport over secure channel. </tt></font> <br><font size=2><tt>Scott: say nothing about signatures in any of the individual protocols. Schema permits signing of messages for protocols that do not provide integrity protection. </tt></font> <br> <br><font size=2><tt><b>3.6 Federated Name Registration Protocol</b></tt></font> <br><font size=2><tt>Prateek: Has anyone deployed this protocol? Concerned that this may be a niche protocol. </tt></font> <br><font size=2><tt>Conor: From IDP side found this useful for consolidating accounts. </tt></font> <br><font size=2><tt>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. </tt></font> <br><font size=2><tt>Eve: Have to address notion that we have multiple protocols now. </tt></font> <br><font size=2><tt>Prateek: How to roll over persistent pseudonyms</tt></font> <br><font size=2><tt>Prateek: IDP pushes out new proposed identifier, SP pushes proposed identifiers to IDP (more challenging)</tt></font> <br><font size=2><tt>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 obviscate it in any way. </tt></font> <br><font size=2><tt>Prateek: Still have concerns about implementability and deployability. </tt></font> <br><font size=2><tt>Eve: Need a conformance document story by next F2F</tt></font> <br><font size=2><tt>Conor: older systems don't cross domain boundaries but this is changing.</tt></font> <br><font size=2><tt>Rob: Have to deal with attestations before we go to standards bodies. Need implementations to justify all parts of the specs. </tt></font> <br><font size=2><tt>Eve: Require 3 or more attestations for use of spec. Conformance document should reflect lines numbers targeted for attestations (implementations). </tt></font> <br><font size=2><tt>Hal: Not all useful features will be implemented in first versions of products. </tt></font> <br><font size=2><tt>Conor: Use case, establish initial connection with social security number and later change the ID to something not connected to ss#</tt></font> <br><font size=2><tt>Eve: OASIS requires some minimal community wants this and some companies were able to implement. SAML usually has a higher bar than this.</tt></font> <br> <br><font size=2><tt><b>3.7 Federation Termination Protocol</b></tt></font> <br><font size=2><tt>Scott: Name is wrong. "I am no longer going to talk about John anymore"</tt></font> <br><font size=2><tt>RL Bob: Unregister Name Identifier (to match Register protocol)</tt></font> <br><font size=2><tt>Scott: Change RegisterNameIdentifier to deregister if no new name identifier is specified.</tt></font> <br><font size=2><tt>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. </tt></font> <br><font size=2><tt><b>Action for Scott:</b> propose change to RegisterNameIdentifier to handle unregister case and consider specifying an attribute that identifies intent of operation. </tt></font> <br><font size=2><tt> </tt></font> <br><font size=2><tt><b>3.8 Single Logout Protocol</b></tt></font> <br><font size=2><tt>John Kemp: No change since last F2F. Only addition was reason attribute. Reason for logout (previously proposed by Hal)</tt></font> <br><font size=2><tt>Hal: Who is doing logout and why</tt></font> <br><font size=2><tt>John Kemp: Still have questions on whether you want to specify this information or not. </tt></font> <br><font size=2><tt>Eve: It's only a string.</tt></font> <br><font size=2><tt>John Kemp: Should be a URI (mistake)</tt></font> <br><font size=2><tt>Eve: session index changed to element (not attribute) is this correct? </tt></font> <br><font size=2><tt>Conor: not attribute of Logout request (maybe this should not be an attribute)</tt></font> <br><font size=2><tt>John Kemp: this should be an element in this instance (because not an attribute of logout request)</tt></font> <br><font size=2><tt>Eve: throughout SAML need to examine style of attribute versus element</tt></font> <br><font size=2><tt>Conor: If SessionIndex is required in assertion request than it should be required here. </tt></font> <br><font size=2><tt>John Kemp: need to think about whether the above is true or not. </tt></font> <br><font size=2><tt><b>Action John Kemp:</b> Review the rational behind SessionIndex</tt></font> <br><font size=2><tt>Conor: Only time you wouldn't include SessionIndex is if there is no possibility of more than one session. </tt></font> <br><font size=2><tt>Conor: Can you set an attribute to specify if no SessionIndex than do a logout on all sessions. </tt></font> <br><font size=2><tt>John Kemp: Need to add a reason attribute on logout request to specify if user's credentials were compromised. </tt></font> <br><font size=2><tt> </tt></font> <br><font size=2><tt><b>3.9 Name Identifier Mapping Protocol</b></tt></font> <br><font size=2><tt>Scott: Case where Name Identifiers are not globally unique.</tt></font> <br><font size=2><tt>Conor: RSA was asking for this. </tt></font> <br><font size=2><tt>Prateek: Concerned about deployment and conformance. What is the use case for this?</tt></font> <br><font size=2><tt>Eve: What profiles use these new protocols?</tt></font> <br><font size=2><tt>Scott: Do they need to be profiled? Is there another generality that profiling is needed.</tt></font> <br><font size=2><tt>Eve: Profiles are embodiment of use cases. </tt></font> <br><font size=2><tt>Scott: Do we need to create profiles to talk about protocols at a conformance level?</tt></font> <br><font size=2><tt>John Kemp: Need to define relationships between protocols, bindings and profiles. </tt></font> <br><font size=2><tt>Eve: Issue - what protocols are reflected in profiles?</tt></font> <br><font size=2><tt>Scott: A lot of work to create "null" profile to hang conformance statements off. </tt></font> <br><font size=2><tt>Eve: Can several protocols be combined into one profile?</tt></font> <br><font size=2><tt> </tt></font> <br><font size=2><tt><b>Section 5 </b></tt></font> <br><font size=2><tt>Needs editorial work</tt></font> <br> <br><font size=2><tt><b>Document in general </b></tt></font> <br><font size=2><tt>Conor: show examples of assertions in document?</tt></font> <br><font size=2><tt>Eve: would also be good to show complete use cases in implementation guide. </tt></font> <br> <br><font size=2><tt><br> <b>3:00-3:15: Break</b></tt></font> <br><font size=2><tt><b>Proposed solution for assertion-level subjects <br> (includes Subject-less assertions)</b><br> Thread begins with<br> http://lists.oasis-open.org/archives/security-services/200403/msg00028.html</tt></font> <br> <br><font size=2><tt>Scott: Subject may be specified in a way that is not consistent with SAML </tt></font> <br><font size=2><tt>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. </tt></font> <br><font size=2><tt>Conor: specified that subject is implied.</tt></font> <br><font size=2><tt>Scott: Not legal to have nothing</tt></font> <br><font size=2><tt>Scott: Lots of queries don't make sense without a subject. </tt></font> <br><font size=2><tt>Eve: Use framework to make security assertions (with subjectless statements). SAML changed the way subjects are handled which creates an issue for XACML use. </tt></font> <br><font size=2><tt>Irving: Only profile assertions with subject information for SAML (don't prevent some other group from using it without subjects)</tt></font> <br><font size=2><tt>Conor: Can specify each statement in SAML requires a subject. </tt></font> <br><font size=2><tt>Scott: Too hard to create restrictions in schema (subject required for SAML statements). Easier to express this in prose. </tt></font> <br><font size=2><tt>Scott: don't want to create profiles to show information in core (to show subjects). </tt></font> <br><font size=2><tt>Hal: XACML wants to do authorization decisions correctly. </tt></font> <br><font size=2><tt>Rob: SAML is an assertion framework. Others might want to use the assertion framework. </tt></font> <br><font size=2><tt>Conor: Summary: Ok with subjectless assertion, is SAML we document in prose that subject is required, specified at core level and not profile level. </tt></font> <br><font size=2><tt><b>Action for Eve:</b> Optional subject implemented in core spec prose. Schema shows that subject is optional.</tt></font> <br><font size=2><tt>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.</tt></font> <br><font size=2><tt>Making an explicit design decision that is not really explicit on</tt></font> <br><font size=2><tt>By choosing to add prose to core spec we're making a stealth abstract profile (generic design decision) that applies to all explicit profiles. </tt></font> <br><font size=2><tt>Scott: data model(design) decision to require subjects in all SAML statements. </tt></font> <br><font size=2><tt>Frederick: need to understand a clear data model</tt></font> <br> <br><font size=2><tt><br> <b>Encryption</b><br> <br> http://lists.oasis-open.org/archives/security-services/200403/msg00127.html</tt></font> <br> <br><font size=2><tt>RL Bob: Do we need to protect a SAML message?</tt></font> <br><font size=2><tt>Hal: Most common cases are transport security, SOAP security or protecting assertion (encryption)</tt></font> <br><font size=2><tt>Hal: Deliberately excluded all cases (encrypting any bit). Looked for common cases. </tt></font> <br><font size=2><tt>Conor: Can you make a statment that if you encrypt one attribute then you will encrypt all attributes?</tt></font> <br><font size=2><tt>Hal: Might not need to, an attribute might be a passwd that needs confidentiality</tt></font> <br><font size=2><tt>Hal: We can add other entities to be encrypted to the list if there are reasonable use cases.</tt></font> <br><font size=2><tt>Tim: Does proposal cover integrity protection?</tt></font> <br><font size=2><tt>Irving: Currently can sign whole assertion, are there use cases to sign parts?</tt></font> <br><font size=2><tt>Scott: Encrypt content and leave element in tact or encrypt the element and content. Scott specified encryption in a different way than Hal did. </tt></font> <br><font size=2><tt>Hal: Can use the method that Scott has used.</tt></font> <br><font size=2><tt>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. </tt></font> <br><font size=2><tt>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). </tt></font> <br><font size=2><tt>Scott: Encrypt SAML attribute or SAML attribute value? (Even though we are not encrypting a lot of that same information on the query). </tt></font> <br><font size=2><tt>Hal: If query is not encrypted then you are giving information about the response.</tt></font> <br><font size=2><tt>Hal: would encrypted data be stored in a database? </tt></font> <br><font size=2><tt>Conor: In IDFF concern about leaking information across pseudonyms.</tt></font> <br><font size=2><tt>Hal: Summary: agreement to encrypt SAML Attribute Statement.</tt></font> <br><font size=2><tt>Allow encryption of Assertion Statement, NameIdentifier and Attribute Statement</tt></font> <br><font size=2><tt>Need schema and some examples. </tt></font> <br><font size=2><tt>Tony: Are you only proposing encrypting the whole body? Does their need to be a schema change for use with WSS?</tt></font> <br><font size=2><tt>Greg: Section 2.1.2 of XML Encryption spec. Describes that if you encrypt an element the atrributes on that element are not encrypted. </tt></font> <br><font size=2><tt>Irving: Need to make sure anyone who extends statement should inherit the ability to encrypt the statement. </tt></font> <br> <br><font size=2><tt><b>Action on Hal:</b> revise proposal to include decisions made here along with details on use cases.</tt></font> <br><font size=2><tt><b>Action on Editors: </b>Produce spec text that adheres to proposal for group review.</tt></font> <br><font size=2><tt><b>Action on Hal:</b> Look at SOAP binding and make sure hand waving on WS-Security works.</tt></font> <br> <br><font size=2><tt><b>From Small Issues list (see below)</b></tt></font> <br><font size=2><tt><b>DoNotCache - Why?</b></tt></font> <br><font size=2><tt>Hal: Way to say validity period once.</tt></font> <br><font size=2><tt>Eve: could update the spec to show relationship to validity period. </tt></font> <br><font size=2><tt>Conor: 3 validity times are one issue and single use is another issue.</tt></font> <br><font size=2><tt>Conor: Need to say this is a one-time use token (and time frames are still valid time frames).</tt></font> <br><font size=2><tt>Hal: Advisory at best. PDP could look at how it made the decision. </tt></font> <br><font size=2><tt>Eve: Can we rename this to make it easier to understand use? OneTimeUse?</tt></font> <br><font size=2><tt>Scott: Binding Condition - carry restrictions / rules based on particular binding. Message validity not assertion validity.</tt></font> <br><font size=2><tt>Scott: Need 3 things: 1. Latest time to process assertion in profile (message expiration). 2. Reauthenticate on or after. 3. Assertion validity.</tt></font> <br><font size=2><tt>Rob: May need other conditions besides validity period. </tt></font> <br><font size=2><tt>Conor: Two time periods, Consumption time period and data content validity. Need 3 time specifications to cover these 2 periods. </tt></font> <br><font size=2><tt>Rob: Lifetime of use of the data in the statement has to be tied to the statements not the assertion. </tt></font> <br><font size=2><tt>Conor: Need to add reauthenticate on or after. </tt></font> <br><font size=2><tt>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. </tt></font> <br><font size=2><tt>Irving: Need tight validity interval to make sure assertion is delivered to relying party in reasonable time. </tt></font> <br><font size=2><tt><b>Action for group:</b> Scott made a concrete proposal. Group needs to make comments on proposal.</tt></font> <br><font size=2><tt>http://www.oasis-open.org/apps/org/workgroup/security/download.php/6123/sstc-cantor-profiles-draft-01.pdf <br> </tt></font> <br><font size=2><tt><br> <b>List of "small issues" to discuss from white board (collected during the day)</b></tt></font> <br> <br><font size=2><tt>Encryption key dist (1 or more) + "recipient"</tt></font> <br><font size=2><tt>DoNotCache - Why?</tt></font> <br><font size=2><tt>Privacy Considerations</tt></font> <br><font size=2><tt>Authn Cntx (stmt, decl, claim,....}?</tt></font> <br><font size=2><tt>Authn Method?</tt></font> <br><font size=2><tt>Schema extensibility</tt></font> <br><font size=2><tt>any Attribute - evil?</tt></font> <br><font size=2><tt>"SAML Authority == IDP"?</tt></font> <br><font size=2><tt>Domain Model</tt></font> <br><font size=2><tt>Consent vs Reason</tt></font> <br><font size=2><tt>Element vs Attribute review</tt></font> <br><font size=2><tt>QName prefixes in status</tt></font> <br> <br><font size=2><tt>Session closed at 5:15</tt></font> --=_alternative 007FD2EB85256E67_=--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]