comments on "OGSA Attribute Exchange Profile Version 1.2"
A few comments and questions on this draft: 1) This spec effectively says that all necessary protocols and encodings have already been defined by OASIS (SAMLCore, SAMLBind, SAMLX509, SAMLPRof). If that's the case, and there's no substantive profiling required, it may be more appropriate to make this an informational document. 2) The only 'profiling' statement seems to be a requirement that SAML Attributes conform to the XACML Attribute Profile. Since "Use of WS-TRUST and SAML to access a CVS" requires this, it is good for consistency. However, comments in the doc indicate some disagreement on whether this a requirement. If it changes, I think you should justify the difference in the two specs. 3) Given the reliance on [SAMLX509], it seems this spec is geared toward environments relying on X.509 principal authentication. If so, you might want to make that clear in the introduction. 4) Both this spec and "Use of WS-TRUST and SAML to access a CVS" deal with attribute retrieval. It would be good clarify how this spec fits into the model used in the other WG specs (i.e., Section 3 of the latter spec) to aid readers in understanding where each is intended to be used. You may also want to provide a brief rationale for why the SAML protocol is appropriate for this spec while WS-Trust is appropriate in the latter. 5) I was surprised to see no discussion of mutual authentication, integrity, and confidentiality. The OASIS specs do mention various ways of handling message security, but I don't believe they mandate any specific security mechanisms. Within grids, I would have thought people would want a message security interop profile all implementers would agree to support. Regards, Blair
On 1/10/08, Blair Dillaway <blaird@microsoft.com> wrote:
A few comments and questions on this draft:
Thanks for the feedback, Blair. Please see the comments below.
1) This spec effectively says that all necessary protocols and encodings have already been defined by OASIS (SAMLCore, SAMLBind, SAMLX509, SAMLPRof). If that's the case, and there's no substantive profiling required, it may be more appropriate to make this an informational document.
I tend to agree with you.
2) The only 'profiling' statement seems to be a requirement that SAML Attributes conform to the XACML Attribute Profile. Since "Use of WS-TRUST and SAML to access a CVS" requires this, it is good for consistency. However, comments in the doc indicate some disagreement on whether this a requirement.
I was the one who inserted that comment in the doc and I still feel that way. If all we're interested in is attribute exchange (and that's precisely what this document is about), then the desired attribute profile (if any) is mostly irrelevant. I think the normative statement in section 4.1 about the XACML Attribute Profile can be removed altogether. In that case, your suggestion in (1) above is even more relevant.
If it changes, I think you should justify the difference in the two specs.
I don't think removing the normative language regarding the XACML Attribute Profile leads to an inconsistent family of specifications. On the contrary, removing this restriction makes this specification more usable in general.
3) Given the reliance on [SAMLX509], it seems this spec is geared toward environments relying on X.509 principal authentication. If so, you might want to make that clear in the introduction.
The use case outlined in [SAMLX509] is pretty clear about this, but yes, it can perhaps be mentioned in the introduction to the OGSA Attribute Exchange Profile.
4) Both this spec and "Use of WS-TRUST and SAML to access a CVS" deal with attribute retrieval. It would be good clarify how this spec fits into the model used in the other WG specs (i.e., Section 3 of the latter spec) to aid readers in understanding where each is intended to be used.
Yes, I agree, especially if we choose to convert this to an informational document as you suggest.
You may also want to provide a brief rationale for why the SAML protocol is appropriate for this spec while WS-Trust is appropriate in the latter.
I'm not sure what form this rationale would take. What alternatives to SAML attribute query are there? Moreover, I don't think it's appropriate for this spec to rationalize choices in the other spec.
5) I was surprised to see no discussion of mutual authentication, integrity, and confidentiality. The OASIS specs do mention various ways of handling message security, but I don't believe they mandate any specific security mechanisms.
[SAMLX509] mandates mutual authentication and suggests possible ways to achieve integrity and confidentiality. If you have comments or concerns about the security requirements in [SAMLX509], I encourage you to submit your comments to OASIS while [SAMLX509] remains in its Public Review period (through Feb 9): http://www.oasis-open.org/archives/tc-announce/200712/msg00004.html Also, you may want to review the proposed "SAML V2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems," which has significantly stronger security requirements than [SAMLX509].
Within grids, I would have thought people would want a message security interop profile all implementers would agree to support.
In that case, you may prefer the security requirements of the "SAML V2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems." I really would like to hear your reactions to that profile (but, please, direct your comments to OASIS, not here). I would be interested in hearing other opinions regarding the security requirements in [SAMLX509], and whether they are adequate for the OGSA Attribute Exchange Profile. If not, we have two choices: 1) send comments to OASIS regarding [SAMLX509] and wait to see how the SSTC responds, or 2) insert the desired security requirements in the OGSA profile. Of course if we add more normative language to the OGSA profile, we won't be able to convert it to an "informational" document, but that's okay, I guess. Tom Scavo NCSA
Hi all, On Sun, 2008-01-13 at 10:26 -0500, Tom Scavo wrote:
On 1/10/08, Blair Dillaway <blaird@microsoft.com> wrote:
A few comments and questions on this draft:
Thanks for the feedback, Blair. Please see the comments below.
1) This spec effectively says that all necessary protocols and encodings have already been defined by OASIS (SAMLCore, SAMLBind, SAMLX509, SAMLPRof). If that's the case, and there's no substantive profiling required, it may be more appropriate to make this an informational document.
I tend to agree with you. It make sense.
2) The only 'profiling' statement seems to be a requirement that SAML Attributes conform to the XACML Attribute Profile. Since "Use of WS-TRUST and SAML to access a CVS" requires this, it is good for consistency. However, comments in the doc indicate some disagreement on whether this a requirement.
I was the one who inserted that comment in the doc and I still feel that way. If all we're interested in is attribute exchange (and that's precisely what this document is about), then the desired attribute profile (if any) is mostly irrelevant. The reason why it was there in the first place, was exactly the one Blair mentioned, easier compatibility with the other specifications of the WG. After the discussion, I tended to agree with Tom, that the choice may be left to developers. Probably a warning that using attributes that are convertible to XACML (so are those compliant to the XACML Attribute profile) woudl make interopration wiht other spec easier should be in a overall architectuire document.
I think the normative statement in section 4.1 about the XACML Attribute Profile can be removed altogether. In that case, your suggestion in (1) above is even more relevant.
If it changes, I think you should justify the difference in the two specs.
I don't think removing the normative language regarding the XACML Attribute Profile leads to an inconsistent family of specifications. On the contrary, removing this restriction makes this specification more usable in general.
3) Given the reliance on [SAMLX509], it seems this spec is geared toward environments relying on X.509 principal authentication. If so, you might want to make that clear in the introduction.
The use case outlined in [SAMLX509] is pretty clear about this, but yes, it can perhaps be mentioned in the introduction to the OGSA Attribute Exchange Profile. Agreed.
4) Both this spec and "Use of WS-TRUST and SAML to access a CVS" deal with attribute retrieval. It would be good clarify how this spec fits into the model used in the other WG specs (i.e., Section 3 of the latter spec) to aid readers in understanding where each is intended to be used.
Yes, I agree, especially if we choose to convert this to an informational document as you suggest. There's the Functional Components document for that. You're suggesting that a brief review of that be done also in the other specs? Infact, the requets decision specs has an architecture overview. I thin that having the architecture once in the architectire document may suffice. This is also one concerns that others have, to include an architecture overview in the specifics specs.
You may also want to provide a brief rationale for why the SAML protocol is appropriate for this spec while WS-Trust is appropriate in the latter.
I'm not sure what form this rationale would take. What alternatives to SAML attribute query are there? Moreover, I don't think it's appropriate for this spec to rationalize choices in the other spec.
The protocols are different. WS-Trust is used because you need to send an assertion to the service and get an assertion back. SAML attribute queries cannot do that. But I'll leave David comments on that.
5) I was surprised to see no discussion of mutual authentication, integrity, and confidentiality. The OASIS specs do mention various ways of handling message security, but I don't believe they mandate any specific security mechanisms.
[SAMLX509] mandates mutual authentication and suggests possible ways to achieve integrity and confidentiality. If you have comments or concerns about the security requirements in [SAMLX509], I encourage you to submit your comments to OASIS while [SAMLX509] remains in its Public Review period (through Feb 9):
http://www.oasis-open.org/archives/tc-announce/200712/msg00004.html
Also, you may want to review the proposed "SAML V2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems," which has significantly stronger security requirements than [SAMLX509].
Within grids, I would have thought people would want a message security interop profile all implementers would agree to support.
In that case, you may prefer the security requirements of the "SAML V2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems." I really would like to hear your reactions to that profile (but, please, direct your comments to OASIS, not here).
I would be interested in hearing other opinions regarding the security requirements in [SAMLX509], and whether they are adequate for the OGSA Attribute Exchange Profile. If not, we have two choices: 1) send comments to OASIS regarding [SAMLX509] and wait to see how the SSTC responds, or 2) insert the desired security requirements in the OGSA profile. Of course if we add more normative language to the OGSA profile, we won't be able to convert it to an "informational" document, but that's okay, I guess.
I think the requirements in SAMLX509 are appropiate. But a similar discussion was made for the authz decision spec, without reaching a real agreement. Valerio
Hi All Valerio Venturi wrote:
Hi all,
On Sun, 2008-01-13 at 10:26 -0500, Tom Scavo wrote:
On 1/10/08, Blair Dillaway <blaird@microsoft.com> wrote:
A few comments and questions on this draft: Thanks for the feedback, Blair. Please see the comments below.
1) This spec effectively says that all necessary protocols and encodings have already been defined by OASIS (SAMLCore, SAMLBind, SAMLX509, SAMLPRof). If that's the case, and there's no substantive profiling required, it may be more appropriate to make this an informational document. I tend to agree with you. It make sense.
2) The only 'profiling' statement seems to be a requirement that SAML Attributes conform to the XACML Attribute Profile. Since "Use of WS-TRUST and SAML to access a CVS" requires this, it is good for consistency. However, comments in the doc indicate some disagreement on whether this a requirement. I was the one who inserted that comment in the doc and I still feel that way. If all we're interested in is attribute exchange (and that's precisely what this document is about), then the desired attribute profile (if any) is mostly irrelevant.
I tend to disagree with Tom. This is a profile document that we are writing, to aid interworking. Given that it is a profile, then it cannot be irrelevant which attribute profile is used. We should standardise on one. The XACML one is the most appropriate one. If you want to use another attribute profile, then you can write a second and different attribute exchange profile document. Alternatively if you allow multiple profiles to be used here, then the CVS will need to be told which profile is being used in order to convert the assertions into the XACML attributes for use by the PDP. So flexibility in this profile means more work by the CVS to map from different profiles into XACML attributes.
The reason why it was there in the first place, was exactly the one Blair mentioned, easier compatibility with the other specifications of the WG.
Also it aids interworking, and cuts down implementation options. That is the purpose of a profile. After the discussion, I tended to agree with Tom, that the
choice may be left to developers. Probably a warning that using attributes that are convertible to XACML (so are those compliant to the XACML Attribute profile) woudl make interopration wiht other spec easier should be in a overall architectuire document.
If we are writing an interoperability profile then we should eliminate as many options as possible. That is the purpose of profiles. If you leave the choice open, you do a dis-service to users and implementors alike who will find that their implementations wont interwork or have to write more code to cater for different formats.
I think the normative statement in section 4.1 about the XACML Attribute Profile can be removed altogether.
I disagree In that case, your
suggestion in (1) above is even more relevant.
If it changes, I think you should justify the difference in the two specs. I don't think removing the normative language regarding the XACML Attribute Profile leads to an inconsistent family of specifications. On the contrary, removing this restriction makes this specification more usable in general.
But that is not the purpose of this (or any) profile. A profile is designed to restrict usage, not generalise it. Base standards are generic, profiles are very specific.
3) Given the reliance on [SAMLX509], it seems this spec is geared toward environments relying on X.509 principal authentication. If so, you might want to make that clear in the introduction. The use case outlined in [SAMLX509] is pretty clear about this, but yes, it can perhaps be mentioned in the introduction to the OGSA Attribute Exchange Profile. Agreed.
4) Both this spec and "Use of WS-TRUST and SAML to access a CVS" deal with attribute retrieval. It would be good clarify how this spec fits into the model used in the other WG specs (i.e., Section 3 of the latter spec) to aid readers in understanding where each is intended to be used. Yes, I agree, especially if we choose to convert this to an informational document as you suggest. There's the Functional Components document for that.
I agree. We dont want to duplicate the functional components document too much in the profiles. Rather we should simply point the reader to the Functional Components document. You're suggesting
that a brief review of that be done also in the other specs? Infact, the requets decision specs has an architecture overview. I thin that having the architecture once in the architectire document may suffice. This is also one concerns that others have, to include an architecture overview in the specifics specs.
You may also want to provide a brief rationale for why the SAML protocol is appropriate for this spec while WS-Trust is appropriate in the latter. I'm not sure what form this rationale would take. What alternatives to SAML attribute query are there? Moreover, I don't think it's appropriate for this spec to rationalize choices in the other spec.
The protocols are different. WS-Trust is used because you need to send an assertion to the service and get an assertion back. SAML attribute queries cannot do that. But I'll leave David comments on that.
WS-Trust is converting from credentials (signed assertions) into XACML attributes for use by the PDP, according to a set of policy rules that are under the control of the resource provider. The SAML attribute queries are designed to fetch the signed assertions from remote attribute authorities, which are under the control of a privacy policy set by the attribute authority. The resource provider has little or no control over this. regards David
5) I was surprised to see no discussion of mutual authentication, integrity, and confidentiality. The OASIS specs do mention various ways of handling message security, but I don't believe they mandate any specific security mechanisms. [SAMLX509] mandates mutual authentication and suggests possible ways to achieve integrity and confidentiality. If you have comments or concerns about the security requirements in [SAMLX509], I encourage you to submit your comments to OASIS while [SAMLX509] remains in its Public Review period (through Feb 9):
http://www.oasis-open.org/archives/tc-announce/200712/msg00004.html
Also, you may want to review the proposed "SAML V2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems," which has significantly stronger security requirements than [SAMLX509].
Within grids, I would have thought people would want a message security interop profile all implementers would agree to support. In that case, you may prefer the security requirements of the "SAML V2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems." I really would like to hear your reactions to that profile (but, please, direct your comments to OASIS, not here).
I would be interested in hearing other opinions regarding the security requirements in [SAMLX509], and whether they are adequate for the OGSA Attribute Exchange Profile. If not, we have two choices: 1) send comments to OASIS regarding [SAMLX509] and wait to see how the SSTC responds, or 2) insert the desired security requirements in the OGSA profile. Of course if we add more normative language to the OGSA profile, we won't be able to convert it to an "informational" document, but that's okay, I guess.
I think the requirements in SAMLX509 are appropiate. But a similar discussion was made for the authz decision spec, without reaching a real agreement.
Valerio
-- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
-- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************
Okay, I don't feel too strongly about this, so David's suggestions are fine with me. If I may make two points: 1. If we leave the normative statement re the XACML Attribute Profile in this document, then it can't be converted to an informational document as suggested by Blair. I don't have a problem with that, I'm just pointing it out. 2. An attribute that satisfies the XACML Attribute Profile can satisfy other profiles simultaneously. In particular, an attribute can satisfy both the XACML Attribute Profile and the X.500/LDAP Attribute Profile (see the last example in section 8 of SAML2Prof). I don't think we have to say anything about this in the document, I just wanted to mention it. Tom On Jan 16, 2008 5:17 PM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Hi All
Valerio Venturi wrote:
Hi all,
On Sun, 2008-01-13 at 10:26 -0500, Tom Scavo wrote:
On 1/10/08, Blair Dillaway <blaird@microsoft.com> wrote:
A few comments and questions on this draft: Thanks for the feedback, Blair. Please see the comments below.
1) This spec effectively says that all necessary protocols and encodings have already been defined by OASIS (SAMLCore, SAMLBind, SAMLX509, SAMLPRof). If that's the case, and there's no substantive profiling required, it may be more appropriate to make this an informational document. I tend to agree with you. It make sense.
2) The only 'profiling' statement seems to be a requirement that SAML Attributes conform to the XACML Attribute Profile. Since "Use of WS-TRUST and SAML to access a CVS" requires this, it is good for consistency. However, comments in the doc indicate some disagreement on whether this a requirement. I was the one who inserted that comment in the doc and I still feel that way. If all we're interested in is attribute exchange (and that's precisely what this document is about), then the desired attribute profile (if any) is mostly irrelevant.
I tend to disagree with Tom. This is a profile document that we are writing, to aid interworking. Given that it is a profile, then it cannot be irrelevant which attribute profile is used. We should standardise on one. The XACML one is the most appropriate one. If you want to use another attribute profile, then you can write a second and different attribute exchange profile document.
Alternatively if you allow multiple profiles to be used here, then the CVS will need to be told which profile is being used in order to convert the assertions into the XACML attributes for use by the PDP. So flexibility in this profile means more work by the CVS to map from different profiles into XACML attributes.
The reason why it was there in the first place, was exactly the one Blair mentioned, easier compatibility with the other specifications of the WG.
Also it aids interworking, and cuts down implementation options. That is the purpose of a profile.
After the discussion, I tended to agree with Tom, that the
choice may be left to developers. Probably a warning that using attributes that are convertible to XACML (so are those compliant to the XACML Attribute profile) woudl make interopration wiht other spec easier should be in a overall architectuire document.
If we are writing an interoperability profile then we should eliminate as many options as possible. That is the purpose of profiles. If you leave the choice open, you do a dis-service to users and implementors alike who will find that their implementations wont interwork or have to write more code to cater for different formats.
I think the normative statement in section 4.1 about the XACML Attribute Profile can be removed altogether.
I disagree
In that case, your
suggestion in (1) above is even more relevant.
If it changes, I think you should justify the difference in the two specs. I don't think removing the normative language regarding the XACML Attribute Profile leads to an inconsistent family of specifications. On the contrary, removing this restriction makes this specification more usable in general.
But that is not the purpose of this (or any) profile. A profile is designed to restrict usage, not generalise it. Base standards are generic, profiles are very specific.
3) Given the reliance on [SAMLX509], it seems this spec is geared toward environments relying on X.509 principal authentication. If so, you might want to make that clear in the introduction. The use case outlined in [SAMLX509] is pretty clear about this, but yes, it can perhaps be mentioned in the introduction to the OGSA Attribute Exchange Profile. Agreed.
4) Both this spec and "Use of WS-TRUST and SAML to access a CVS" deal with attribute retrieval. It would be good clarify how this spec fits into the model used in the other WG specs (i.e., Section 3 of the latter spec) to aid readers in understanding where each is intended to be used. Yes, I agree, especially if we choose to convert this to an informational document as you suggest. There's the Functional Components document for that.
I agree. We dont want to duplicate the functional components document too much in the profiles. Rather we should simply point the reader to the Functional Components document.
You're suggesting
that a brief review of that be done also in the other specs? Infact, the requets decision specs has an architecture overview. I thin that having the architecture once in the architectire document may suffice. This is also one concerns that others have, to include an architecture overview in the specifics specs.
You may also want to provide a brief rationale for why the SAML protocol is appropriate for this spec while WS-Trust is appropriate in the latter. I'm not sure what form this rationale would take. What alternatives to SAML attribute query are there? Moreover, I don't think it's appropriate for this spec to rationalize choices in the other spec.
The protocols are different. WS-Trust is used because you need to send an assertion to the service and get an assertion back. SAML attribute queries cannot do that. But I'll leave David comments on that.
WS-Trust is converting from credentials (signed assertions) into XACML attributes for use by the PDP, according to a set of policy rules that are under the control of the resource provider.
The SAML attribute queries are designed to fetch the signed assertions from remote attribute authorities, which are under the control of a privacy policy set by the attribute authority. The resource provider has little or no control over this.
regards
David
5) I was surprised to see no discussion of mutual authentication, integrity, and confidentiality. The OASIS specs do mention various ways of handling message security, but I don't believe they mandate any specific security mechanisms. [SAMLX509] mandates mutual authentication and suggests possible ways to achieve integrity and confidentiality. If you have comments or concerns about the security requirements in [SAMLX509], I encourage you to submit your comments to OASIS while [SAMLX509] remains in its Public Review period (through Feb 9):
http://www.oasis-open.org/archives/tc-announce/200712/msg00004.html
Also, you may want to review the proposed "SAML V2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems," which has significantly stronger security requirements than [SAMLX509].
Within grids, I would have thought people would want a message security interop profile all implementers would agree to support. In that case, you may prefer the security requirements of the "SAML V2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems." I really would like to hear your reactions to that profile (but, please, direct your comments to OASIS, not here).
I would be interested in hearing other opinions regarding the security requirements in [SAMLX509], and whether they are adequate for the OGSA Attribute Exchange Profile. If not, we have two choices: 1) send comments to OASIS regarding [SAMLX509] and wait to see how the SSTC responds, or 2) insert the desired security requirements in the OGSA profile. Of course if we add more normative language to the OGSA profile, we won't be able to convert it to an "informational" document, but that's okay, I guess.
I think the requirements in SAMLX509 are appropiate. But a similar discussion was made for the authz decision spec, without reaching a real agreement.
Valerio
-- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
--
***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5
*****************************************************************
Hi Tom Tom Scavo wrote:
Okay, I don't feel too strongly about this, so David's suggestions are fine with me. If I may make two points:
1. If we leave the normative statement re the XACML Attribute Profile in this document, then it can't be converted to an informational document as suggested by Blair. I don't have a problem with that, I'm just pointing it out.
2. An attribute that satisfies the XACML Attribute Profile can satisfy other profiles simultaneously. In particular, an attribute can satisfy both the XACML Attribute Profile and the X.500/LDAP Attribute Profile (see the last example in section 8 of SAML2Prof). I don't think we have to say anything about this in the document, I just wanted to mention it.
This is a good point that you make, and i think it should be made in the document as a footnote such as Note. An attribute can simultaneously satisfy the XACML Attribute Profile and other profiles as well such as the X.500/LDAP Attribute Profile. This specification does not prejudice such profiling. regards David
Profile
Tom
On Jan 16, 2008 5:17 PM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Hi All
Valerio Venturi wrote:
Hi all,
On Sun, 2008-01-13 at 10:26 -0500, Tom Scavo wrote:
On 1/10/08, Blair Dillaway <blaird@microsoft.com> wrote:
A few comments and questions on this draft: Thanks for the feedback, Blair. Please see the comments below.
1) This spec effectively says that all necessary protocols and encodings have already been defined by OASIS (SAMLCore, SAMLBind, SAMLX509, SAMLPRof). If that's the case, and there's no substantive profiling required, it may be more appropriate to make this an informational document. I tend to agree with you. It make sense.
2) The only 'profiling' statement seems to be a requirement that SAML Attributes conform to the XACML Attribute Profile. Since "Use of WS-TRUST and SAML to access a CVS" requires this, it is good for consistency. However, comments in the doc indicate some disagreement on whether this a requirement. I was the one who inserted that comment in the doc and I still feel that way. If all we're interested in is attribute exchange (and that's precisely what this document is about), then the desired attribute profile (if any) is mostly irrelevant. I tend to disagree with Tom. This is a profile document that we are writing, to aid interworking. Given that it is a profile, then it cannot be irrelevant which attribute profile is used. We should standardise on one. The XACML one is the most appropriate one. If you want to use another attribute profile, then you can write a second and different attribute exchange profile document.
Alternatively if you allow multiple profiles to be used here, then the CVS will need to be told which profile is being used in order to convert the assertions into the XACML attributes for use by the PDP. So flexibility in this profile means more work by the CVS to map from different profiles into XACML attributes.
The reason why it was there in the first place, was exactly the one Blair mentioned, easier compatibility with the other specifications of the WG. Also it aids interworking, and cuts down implementation options. That is the purpose of a profile.
After the discussion, I tended to agree with Tom, that the
choice may be left to developers. Probably a warning that using attributes that are convertible to XACML (so are those compliant to the XACML Attribute profile) woudl make interopration wiht other spec easier should be in a overall architectuire document. If we are writing an interoperability profile then we should eliminate as many options as possible. That is the purpose of profiles. If you leave the choice open, you do a dis-service to users and implementors alike who will find that their implementations wont interwork or have to write more code to cater for different formats.
I think the normative statement in section 4.1 about the XACML Attribute Profile can be removed altogether. I disagree
In that case, your
suggestion in (1) above is even more relevant.
If it changes, I think you should justify the difference in the two specs. I don't think removing the normative language regarding the XACML Attribute Profile leads to an inconsistent family of specifications. On the contrary, removing this restriction makes this specification more usable in general. But that is not the purpose of this (or any) profile. A profile is designed to restrict usage, not generalise it. Base standards are generic, profiles are very specific.
3) Given the reliance on [SAMLX509], it seems this spec is geared toward environments relying on X.509 principal authentication. If so, you might want to make that clear in the introduction. The use case outlined in [SAMLX509] is pretty clear about this, but yes, it can perhaps be mentioned in the introduction to the OGSA Attribute Exchange Profile. Agreed.
4) Both this spec and "Use of WS-TRUST and SAML to access a CVS" deal with attribute retrieval. It would be good clarify how this spec fits into the model used in the other WG specs (i.e., Section 3 of the latter spec) to aid readers in understanding where each is intended to be used. Yes, I agree, especially if we choose to convert this to an informational document as you suggest. There's the Functional Components document for that. I agree. We dont want to duplicate the functional components document too much in the profiles. Rather we should simply point the reader to the Functional Components document.
You're suggesting
that a brief review of that be done also in the other specs? Infact, the requets decision specs has an architecture overview. I thin that having the architecture once in the architectire document may suffice. This is also one concerns that others have, to include an architecture overview in the specifics specs.
You may also want to provide a brief rationale for why the SAML protocol is appropriate for this spec while WS-Trust is appropriate in the latter. I'm not sure what form this rationale would take. What alternatives to SAML attribute query are there? Moreover, I don't think it's appropriate for this spec to rationalize choices in the other spec. The protocols are different. WS-Trust is used because you need to send an assertion to the service and get an assertion back. SAML attribute queries cannot do that. But I'll leave David comments on that. WS-Trust is converting from credentials (signed assertions) into XACML attributes for use by the PDP, according to a set of policy rules that are under the control of the resource provider.
The SAML attribute queries are designed to fetch the signed assertions from remote attribute authorities, which are under the control of a privacy policy set by the attribute authority. The resource provider has little or no control over this.
regards
David
5) I was surprised to see no discussion of mutual authentication, integrity, and confidentiality. The OASIS specs do mention various ways of handling message security, but I don't believe they mandate any specific security mechanisms. [SAMLX509] mandates mutual authentication and suggests possible ways to achieve integrity and confidentiality. If you have comments or concerns about the security requirements in [SAMLX509], I encourage you to submit your comments to OASIS while [SAMLX509] remains in its Public Review period (through Feb 9):
http://www.oasis-open.org/archives/tc-announce/200712/msg00004.html
Also, you may want to review the proposed "SAML V2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems," which has significantly stronger security requirements than [SAMLX509].
Within grids, I would have thought people would want a message security interop profile all implementers would agree to support. In that case, you may prefer the security requirements of the "SAML V2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems." I really would like to hear your reactions to that profile (but, please, direct your comments to OASIS, not here).
I would be interested in hearing other opinions regarding the security requirements in [SAMLX509], and whether they are adequate for the OGSA Attribute Exchange Profile. If not, we have two choices: 1) send comments to OASIS regarding [SAMLX509] and wait to see how the SSTC responds, or 2) insert the desired security requirements in the OGSA profile. Of course if we add more normative language to the OGSA profile, we won't be able to convert it to an "informational" document, but that's okay, I guess. I think the requirements in SAMLX509 are appropiate. But a similar discussion was made for the authz decision spec, without reaching a real agreement.
Valerio
-- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
--
***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5
*****************************************************************
-- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************
That's a good suggestion, David. Unless anyone has objections, I will produce version 1.3 of this document. I'll take into account both Blair's and David's comments. Valerio, is that okay with you? Tom On Jan 16, 2008 6:05 PM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Hi Tom
Tom Scavo wrote:
Okay, I don't feel too strongly about this, so David's suggestions are fine with me. If I may make two points:
1. If we leave the normative statement re the XACML Attribute Profile in this document, then it can't be converted to an informational document as suggested by Blair. I don't have a problem with that, I'm just pointing it out.
2. An attribute that satisfies the XACML Attribute Profile can satisfy other profiles simultaneously. In particular, an attribute can satisfy both the XACML Attribute Profile and the X.500/LDAP Attribute Profile (see the last example in section 8 of SAML2Prof). I don't think we have to say anything about this in the document, I just wanted to mention it.
This is a good point that you make, and i think it should be made in the document as a footnote such as
Note. An attribute can simultaneously satisfy the XACML Attribute Profile and other profiles as well such as the X.500/LDAP Attribute Profile. This specification does not prejudice such profiling.
regards
David
Profile
Tom
On Jan 16, 2008 5:17 PM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Hi All
Valerio Venturi wrote:
Hi all,
On Sun, 2008-01-13 at 10:26 -0500, Tom Scavo wrote:
On 1/10/08, Blair Dillaway <blaird@microsoft.com> wrote:
A few comments and questions on this draft: Thanks for the feedback, Blair. Please see the comments below.
1) This spec effectively says that all necessary protocols and encodings have already been defined by OASIS (SAMLCore, SAMLBind, SAMLX509, SAMLPRof). If that's the case, and there's no substantive profiling required, it may be more appropriate to make this an informational document. I tend to agree with you. It make sense.
2) The only 'profiling' statement seems to be a requirement that SAML Attributes conform to the XACML Attribute Profile. Since "Use of WS-TRUST and SAML to access a CVS" requires this, it is good for consistency. However, comments in the doc indicate some disagreement on whether this a requirement. I was the one who inserted that comment in the doc and I still feel that way. If all we're interested in is attribute exchange (and that's precisely what this document is about), then the desired attribute profile (if any) is mostly irrelevant. I tend to disagree with Tom. This is a profile document that we are writing, to aid interworking. Given that it is a profile, then it cannot be irrelevant which attribute profile is used. We should standardise on one. The XACML one is the most appropriate one. If you want to use another attribute profile, then you can write a second and different attribute exchange profile document.
Alternatively if you allow multiple profiles to be used here, then the CVS will need to be told which profile is being used in order to convert the assertions into the XACML attributes for use by the PDP. So flexibility in this profile means more work by the CVS to map from different profiles into XACML attributes.
The reason why it was there in the first place, was exactly the one Blair mentioned, easier compatibility with the other specifications of the WG. Also it aids interworking, and cuts down implementation options. That is the purpose of a profile.
After the discussion, I tended to agree with Tom, that the
choice may be left to developers. Probably a warning that using attributes that are convertible to XACML (so are those compliant to the XACML Attribute profile) woudl make interopration wiht other spec easier should be in a overall architectuire document. If we are writing an interoperability profile then we should eliminate as many options as possible. That is the purpose of profiles. If you leave the choice open, you do a dis-service to users and implementors alike who will find that their implementations wont interwork or have to write more code to cater for different formats.
I think the normative statement in section 4.1 about the XACML Attribute Profile can be removed altogether. I disagree
In that case, your
suggestion in (1) above is even more relevant.
If it changes, I think you should justify the difference in the two specs. I don't think removing the normative language regarding the XACML Attribute Profile leads to an inconsistent family of specifications. On the contrary, removing this restriction makes this specification more usable in general. But that is not the purpose of this (or any) profile. A profile is designed to restrict usage, not generalise it. Base standards are generic, profiles are very specific.
3) Given the reliance on [SAMLX509], it seems this spec is geared toward environments relying on X.509 principal authentication. If so, you might want to make that clear in the introduction. The use case outlined in [SAMLX509] is pretty clear about this, but yes, it can perhaps be mentioned in the introduction to the OGSA Attribute Exchange Profile. Agreed.
4) Both this spec and "Use of WS-TRUST and SAML to access a CVS" deal with attribute retrieval. It would be good clarify how this spec fits into the model used in the other WG specs (i.e., Section 3 of the latter spec) to aid readers in understanding where each is intended to be used. Yes, I agree, especially if we choose to convert this to an informational document as you suggest. There's the Functional Components document for that. I agree. We dont want to duplicate the functional components document too much in the profiles. Rather we should simply point the reader to the Functional Components document.
You're suggesting
that a brief review of that be done also in the other specs? Infact, the requets decision specs has an architecture overview. I thin that having the architecture once in the architectire document may suffice. This is also one concerns that others have, to include an architecture overview in the specifics specs.
You may also want to provide a brief rationale for why the SAML protocol is appropriate for this spec while WS-Trust is appropriate in the latter. I'm not sure what form this rationale would take. What alternatives to SAML attribute query are there? Moreover, I don't think it's appropriate for this spec to rationalize choices in the other spec. The protocols are different. WS-Trust is used because you need to send an assertion to the service and get an assertion back. SAML attribute queries cannot do that. But I'll leave David comments on that. WS-Trust is converting from credentials (signed assertions) into XACML attributes for use by the PDP, according to a set of policy rules that are under the control of the resource provider.
The SAML attribute queries are designed to fetch the signed assertions from remote attribute authorities, which are under the control of a privacy policy set by the attribute authority. The resource provider has little or no control over this.
regards
David
5) I was surprised to see no discussion of mutual authentication, integrity, and confidentiality. The OASIS specs do mention various ways of handling message security, but I don't believe they mandate any specific security mechanisms. [SAMLX509] mandates mutual authentication and suggests possible ways to achieve integrity and confidentiality. If you have comments or concerns about the security requirements in [SAMLX509], I encourage you to submit your comments to OASIS while [SAMLX509] remains in its Public Review period (through Feb 9):
http://www.oasis-open.org/archives/tc-announce/200712/msg00004.html
Also, you may want to review the proposed "SAML V2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems," which has significantly stronger security requirements than [SAMLX509].
Within grids, I would have thought people would want a message security interop profile all implementers would agree to support. In that case, you may prefer the security requirements of the "SAML V2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems." I really would like to hear your reactions to that profile (but, please, direct your comments to OASIS, not here).
I would be interested in hearing other opinions regarding the security requirements in [SAMLX509], and whether they are adequate for the OGSA Attribute Exchange Profile. If not, we have two choices: 1) send comments to OASIS regarding [SAMLX509] and wait to see how the SSTC responds, or 2) insert the desired security requirements in the OGSA profile. Of course if we add more normative language to the OGSA profile, we won't be able to convert it to an "informational" document, but that's okay, I guess. I think the requirements in SAMLX509 are appropiate. But a similar discussion was made for the authz decision spec, without reaching a real agreement.
Valerio
-- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
--
***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5
*****************************************************************
--
***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5
*****************************************************************
On Wed, 2008-01-16 at 18:11 -0500, Tom Scavo wrote:
That's a good suggestion, David.
Unless anyone has objections, I will produce version 1.3 of this document. I'll take into account both Blair's and David's comments. Valerio, is that okay with you?
Go ahead. Valerio
participants (4)
-
Blair Dillaway -
David Chadwick -
Tom Scavo -
Valerio Venturi