[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: ISSUE:[UC-4-03:PrivateKeyHost]
This issue primarily deals with the question of how to cryptographically "bind" SAML assertions to a business payload. I will call this composite object a SAML package. In S2ML 0.8a, assertions carried an (optional) field for the senders public key (actually this could also be a <dsig:keyinfo> element) which can carry a more general payload (e.g., a hint about where to find the public key). The sender could sign the entire package with her private key and include information about the corresponding public key in the <dsig:keyinfo> field in the assertion (these are precisely the so-called scoped assertions). The receiver can then authenticate the binding between the SAML assertions and payload using the <dsig:keyinfo> field. This eliminates the possibility of assertions being added or removed from the SAML business package by an intermediary. I worked through the cited references to SACRED, and I dont see them as directly relevant. I am not proposing any new infra-structure for moving credentials around the internet. Instead, the issue is instead one of providing a SAML package sender with appropriate infra-structure for cryptographic binding of assertions to payload. - prateek > ISSUE:[UC-4-03:PrivateKeyHost] > 1. A use-case or use-case scenario comprising steps (a) and (b) aboveshould be > added to the use-case document. > 2. A requirement for supporting "binding" between AuthN assertionsand business > payloads thru digital signature > be added to the use-case document. > 3. This issue has been adequately addressed elsewhere; there is noneed for any > additions to the use-case document. Vote 3. rationale: this is outta scope and is already being addressed elsewhere (tho some SSTC folk are involved) see.. http://www.ietf.org/html.charters/sacred-charter.html http://www.ietf.org/internet-drafts/draft-ietf-sacred-reqs-02.txt http://www.ietf.org/internet-drafts/draft-ietf-sacred-framework-01.txt http://www.ietf.org/internet-drafts/draft-ietf-sacred-scenarios-00.txt Securley Available Credentials; Speaker - Magnus Nystrom http://www.appcluster05.com/images/123/stamon11.pdf >>-----Original Message----- >>From: Jeff Hodges [mailto:jhodges@oblix.com] >>Sent: Saturday, April 07, 2001 4:04 AM >>To: oasis sstc use >>Cc: Darren Platt >>Subject: JeffH's votes RE: Ballot for Issue Groups 2, 3, 4, >>10, 12, and >>13 attached >> >> >>a process comment: we need to define what "end of the day" >>actually means. It >>means to me at this point to call up Darren and ask him when >>he ~really~ needs >>it to be in. Using UTC time might indeed help. >> >> >>> **************** >>> * Group 2 >>> **************** >>> >>> ISSUE:[UC-2-01:AddPolicyAssertions] >>> 1. Remove the non-goal, add this requirement, and refer >>to data in >>> this format as "policy documents." >>> 2. Maintain the non-goal, leave out the requirement. >> >>vote: 2. >> >> >> >>> >>> ISSUE:[UC-2-02:OutsourcedManagement] >>> 1. Add this use-case scenario to the document. >>> 2. Do not add this use-case scenario. >> >>vote: 2. >> >> >>> ISSUE:[UC-2-03:ASP] >>> 1. Add this use-case scenario to the document. >>> 2. Do not add this use-case scenario. >> >> >>vote: 2. >> >> >>> ISSUE:[UC-2-05:EMarketplace] >>> 1. The above scenario should be added to the use cases document. >>> 2. The above scenario should not be added to the document. >> >>Vote: 1. >> >>rationale: it's describing things at a fairly high level of >>abstraction and >>isn't already covered in the present doc >>(draft-sstc-use-strawman-03.html). >>However, I (also) feel that addressing this sort of scenario >>is a lower >>priority than the "web-browser sign-on scenario(s)". >> >> >>> ISSUE:[UC-2-06:EMarketplaceDifferentProtocol] >>> 1. Add this scenario to the document. >>> 2. This use case scenario should not be added to the document. >> >>vote: 2. >> >> >>> ISSUE:[UC-2-07:MultipleEMarketplace] >>> 1. Add this scenario to the document. >>> >>> 2. The above scenario should not be added to the document. >> >>Vote: 2. >> >> >>> ISSUE:[UC-2-08:ebXML] >>> 1. Add this use case scenario to the use case and >>requirements document. >>> 2. Do not add this scenario. >> >>vote: 2. >> >>rationale: needs work. specific mention of "DN" way too deep >>a level for this >>doc (draft-sstc-use-strawman-0x). >> >> >>> ******************* >>> * Group 3 >>> ******************* >> >>overall rationale: for the level of abstraction appropriate in >>draft-sstc-use-strawman-0x, I think we need to only expand >>the existing >>requirement.. >> >> [R-UserSession] SAML shall support web user sessions. >> >>..as-needed. Also, many of the below detailed features ought >>to be expressed as >>"SHOULD" or "MAY" clauses in the so-edited [R-UserSession], >>not as "MUST"s. >> >> >> >>> ISSUE:[UC-3-03:Logout] >>> 1. Add this requirement to SAML. >>> 2. Do not add this requirement to SAML. >> >>Vote: 2. >> >>> ISSUE:[UC-3-05:SessionTermination] >>> 1. Add this requirement to SAML. >>> 2. Do not add this requirement and/or use cases. >> >>Vote: 2. >> >>> ISSUE:[UC-3-06:DestinationLogout] >>> 1. Add this scenario and requirement to SAML. >>> 2. Do not add this scenario or requirement. >> >>Vote: 2. >> >>> ISSUE:[UC-3-8:DestinationSessionTermination] >>> 1. Add this scenario and requirement to SAML. >>> 2. Do not add this scenario or requirement. >> >>Vote: 2. >> >> >>> ISSUE:[UC-3-9:Destination-Time-In] >>> 1. Add this scenario and requirement to SAML. >>> 2. Do not add this scenario or requirement to SAML. >> >>Vote: 2. >> >> >>> *************** >>> * Group 4 >>> *************** >> >>> ISSUE:[UC-4-01:SecurityService] >>> 1. This issue is now obsolete and can be closed as several >>securityservices >>> (shared sessioning, PDP-->PEP relationship) >>> have been identified within S2ML. >>> 2. This issue should be kept open. >> >>Vote: 2. >> >>rationale: the term "security service" is used throughout >>draft-sstc-use-strawman-03 without being clearly defined. We >>should do so. >> >> >> >>> ISSUE:[UC-4-02:AttributeAuthority] >>> 1. A use-case or use-case scenario similar to that >>described above should be >>> added to SAML. >>> 2. This issue is adequately addressed by existing use cases >>and doesnot >>> require further elaboration within SAML. >> >> >>Vote: 2. >> >>rationale: this issue is a result of terminological muddiness in >>draft-sstc-use-strawman-03 et al. draft-sstc-use-strawman-03 >>needs to be >>normalized with draft-sstc-use-domain-03. [the latter perhaps >>should be >>incorporated into the next rev of the former] >> >> >> >> >>> ISSUE:[UC-4-03:PrivateKeyHost] >>> 1. A use-case or use-case scenario comprising steps (a) and >>(b) aboveshould be >>> added to the use-case document. >>> 2. A requirement for supporting "binding" between AuthN >>assertionsand business >>> payloads thru digital signature >>> be added to the use-case document. >>> 3. This issue has been adequately addressed elsewhere; >>there is noneed for any >>> additions to the use-case document. >> >> >>Vote 3. >> >>rationale: this is outta scope and is already being addressed >>elsewhere (tho >>some SSTC folk are involved) see.. >> >>http://www.ietf.org/html.charters/sacred-charter.html >> >>http://www.ietf.org/internet-drafts/draft-ietf-sacred-reqs-02.txt >>http://www.ietf.org/internet-drafts/draft-ietf-sacred-framework-01.txt >>http://www.ietf.org/internet-drafts/draft-ietf-sacred-scenarios-00.txt >> >>Securley Available Credentials; Speaker - Magnus Nystrom >>http://www.appcluster05.com/images/123/stamon11.pdf >> >> >> >> >>> ISSUE:[UC-4-04:SecurityDiscover] >>> 1.Yes, a service could be provided to send authorization >>dataabout a service >>> between security zones. This would require some >>> sort of policy assertions (UC-2-01:AddPolicyAssertions). >>> 2.No, this extends the scope of [OSSML] too far. AuthZ in >>[OSSML]should be >>> concerned with AuthZ attributes of a principal, >>> not of resources. >> >> >>Vote: 2. >> >> >>> ************** >>> * Group 10 >>> ************** >>> >>> ISSUE:[UC-10-01:Framework] >>> 1. Remove the extensibility requirement. >>> 2. Leave the extensibility requirement. >> >> >>Vote 2. >> >>rationale: but we need to extensively re-work it. >> >> >>> ISSUE:[UC-10-02:ExtendAssertionData] >>> 1. Add requirement [CR-10-02:ExtendAssertionData]. >>> 2. Do not add this requirement. >> >>Vote 2. >> >> >> >>> ISSUE:[UC-10-03:ExtendMessageData] >>> 1. Add requirement [CR-10-03:ExtendMessageData]. >>> 2. Do not add this requirement. >> >> >>Vote 2. >> >> >> >>> ISSUE:[UC-10-04:ExtendMessageTypes] >>> 1. Add requirement [CR-10-04:ExtendMessageTypes]. >>> 2. Do not add this requirement. >> >> >>Vote 2. >> >> >> >>> ISSUE:[UC-10-05:ExtendAssertionTypes] >>> 1. Add requirement [CR-10-05:ExtendAssertionTypes]. >>> 2. Do not add this requirement. >> >>Vote 2. >> >> >> >> >>> ISSUE:[UC-10-06:BackwardCompatibleExtensions] >>> 1. Add requirement [CR-10-06-BackwardCompatibleExtensions]. >>> 2. Do not add this requirement. >> >>Vote 1, sorta. >> >>rationale: this actually needs to be mixed-into the >>[R-Extensible] requirement >>statement. >> >> >> >>> ISSUE:[UC-10-07:ExtensionNegotiation] >>> 1. Add requirement [CR-10-07-1:ExtensionNegotiation]. >>> 2. Add non-goal [CR-10-07-2:NoExtensionNegotiation]. >>> 3. Add neither the requirement nor the non-goal. >> >>Vote 1, sorta. >> >>rationale: this actually needs to be mixed-into the >>[R-Extensible] requirement >>statement. I feel that extension negotiation is a "MUST" if >>one's protocol >>supports the notion of extensions. >> >> >> >> >> >>> ************** >>> * Group 12 >>> ************** >>> >>> ISSUE:[UC-12-01:Confidentiality] >>> 1) Add [R-Confidentiality] >>> 2) Do not add [R-Confidentiality] >> >>Vote 1. >> >>comment: but the term "SAML data" is vague and undefined. >> >> >>> ISSUE: [UC-12-02:AssertionConfidentiality] >>> 1) Add the requirement: >>> [R-AssertionConfidentiality] SAML should define a format so >>that individual >>> SAML assertions may be encrypted, independent of protocol bindings. >>> >>> 2) Add the requirement: >>> [R-AssertionConfidentiality] SAML assertions must be >>encrypted, independent >>> of protocol bindings. >>> >>> 3) Add a non-goal: >>> SAML will not define a format for protecting >>confidentiality of individual >>> assertions; confidentiality protection will be left to the protocol >>> bindings. >>> >>> 4) Do not add either requirement or the non-goal. >> >>Vote 4. >> >>rationale: redundant. >> >> >> >> >>> ISSUE: [UC-12-03:BindingConfidentiality] >>> 1) [R-BindingConfidentiality] Bindings SHOULD (in the RFC >>sense) provide a >>> means to protect SAML data from observation by third >>parties. Each protocol >>> binding must include a description of how applications can >>make use of this >>> protection. Examples: S/MIME for MIME, HTTP/S for HTTP. >>> >>> 2) [R-BindingConfidentiality] Each protocol binding must >>always protect SAML >>> data from observation by third parties. >>> >>> 3) Do not add either requirement. >> >> >>Vote: 1. >> >> >> >>> ISSUE:[UC-12-03:EncryptionMethod] >>> 1) Add the requirement: >>> [R-EncryptionMethod] SAML should use XML Encryption. >>> >>> 2) Add the requirement: >>> [R-EncryptionMethod] Because there is no currently >>published standard for >>> encrypting XML, SAML should define its own encryption format. >>> Edit the existing non-goal of not creating new >>cryptographic techniques to >>> allow this. >>> >>> 3) Add no requirement now, but include a note that this >>issue must be >>> revisited in a future version of the SAML spec after XML >>Encryption is >>> published. >>> >>> 4) Do not add any of these requirements or notes. >> >> >>Vote: 4. >> >> >> >>> *************** >>> * Group 13 >>> *************** >>> >>> ISSUE:[UC-13-01:Scalability] >>> 1. Add requirement [CR-13-01-Scalability]. >>> 2. Do not add this requirement. >> >>Vote: 2. >> >> >>> ISSUE:[UC-13-02:EfficientMessages] >>> 1. Add this requirement to the use case and requirements >>document. >>> 2. Leave this requirement out of use case and >>requirements document. >> >>Vote: 1. >> >>rationale: I suppose it's worth stating explicitly. >> >> >>> ISSUE:[UC-13-03:OptionalAuthentication] >>> 1. Add this requirement to the use case and requirements >>document. >>> 2. Leave this requirement out of use case and >>requirements document. >> >>Vote: 2. >> >> >>> ISSUE:[UC-13-04:OptionalSignatures] >>> 1. Add this requirement to the use case and requirements >>document. >>> 2. Leave this requirement out of use case and >>requirements document. >> >>Vote: 2. >> >> >>> ISSUE:[UC-13-05:SecurityPolicy] >>> 1. Add this requirement to the use case and requirements >>document. >>> 2. Leave this requirement out of use case and >>requirements document. >> >> >>Vote: 1. >> >> >> >>> ISSUE:[UC-13-06:ReferenceReqt] >>> 1. Replace [R-Reference] with these requirements. >>> 2. Leave [R-Reference] as it is. >>> 3. Remove mention of references entirely. >> >>Vote: 3. >> >>rationale: "reference" is undefined and vague and way too >>deep into design-time >>detail. >> >> >>--- >>end >> >>------------------------------------------------------------------ >>To unsubscribe from this elist send a message with the single word >>"unsubscribe" in the body to: >>security-use-request@lists.oasis-open.org >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC