![](https://secure.gravatar.com/avatar/6e1526a3d8af0bb09676f1b771810cf4.jpg?s=120&d=mm&r=g)
Dear WG I would like to draw up a table of implementations of the 3 protocol profile docs that we have published (XACML, WS-Trust and SAML AA). The information that would be useful for the group is Profile being implemented: Organisation doing the implementation: Contact details: Short description: (the latter to contain such things as status of implementation, any interworking carried out, where software might be obtained etc. Whatever you feel is appropriate for the WG) regards David -- ***************************************************************** 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 *****************************************************************
![](https://secure.gravatar.com/avatar/aee6f84ca062acc8de6c02fdfa5e23cc.jpg?s=120&d=mm&r=g)
Perhaps also we might identify folk that are applying them and lessons learned that can be shared etc. R. -----Original Message----- From: ogsa-authz-wg-bounces@ogf.org on behalf of David Chadwick Sent: Sat 17/11/2007 11:56 To: OGSA AUTHZ WG Subject: [OGSA-AUTHZ] Implementations Dear WG I would like to draw up a table of implementations of the 3 protocol profile docs that we have published (XACML, WS-Trust and SAML AA). The information that would be useful for the group is Profile being implemented: Organisation doing the implementation: Contact details: Short description: (the latter to contain such things as status of implementation, any interworking carried out, where software might be obtained etc. Whatever you feel is appropriate for the WG) regards David -- ***************************************************************** 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 ***************************************************************** -- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
![](https://secure.gravatar.com/avatar/6e1526a3d8af0bb09676f1b771810cf4.jpg?s=120&d=mm&r=g)
Hi Richard certainly testing by user groups is an important factor, since if I remember correctly your group was one of the first to find deficiencies in the current OGSA SAML specification (GFD 66), that the implementors weren't immediately aware of. So you could replace Profile being implemented by Profile being tested and then fill in the form regards David Richard Sinnott wrote:
Perhaps also we might identify folk that are applying them and lessons learned that can be shared etc.
R.
-----Original Message----- From: ogsa-authz-wg-bounces@ogf.org on behalf of David Chadwick Sent: Sat 17/11/2007 11:56 To: OGSA AUTHZ WG Subject: [OGSA-AUTHZ] Implementations
Dear WG
I would like to draw up a table of implementations of the 3 protocol profile docs that we have published (XACML, WS-Trust and SAML AA).
The information that would be useful for the group is
Profile being implemented: Organisation doing the implementation: Contact details: Short description:
(the latter to contain such things as status of implementation, any interworking carried out, where software might be obtained etc. Whatever you feel is appropriate for the WG)
regards
David
--
***************************************************************** 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
***************************************************************** -- 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 *****************************************************************
![](https://secure.gravatar.com/avatar/25170d7bd06dd4d753053e12888d1bb0.jpg?s=120&d=mm&r=g)
Hi David, Profile being implemented: OGSA Attribute Exchange Profile Organisation doing the implementation: INFN Contact details: valerio.venturi@cnaf.infn.it Short description: VOMS Profile being implemented: XACML Request Context to Obtain an Authorization Decision Organisation doing the implementation: INFN Contact details: valerio.venturi@cnaf.infn.it Short description: gPBox (gLite Policy Box) grid policy based authorization service http://gpbox.forge.cnaf.infn.it Regards, Valerio On Sat, 2007-11-17 at 11:56 +0000, David Chadwick wrote:
Dear WG
I would like to draw up a table of implementations of the 3 protocol profile docs that we have published (XACML, WS-Trust and SAML AA).
The information that would be useful for the group is
Profile being implemented: Organisation doing the implementation: Contact details: Short description:
(the latter to contain such things as status of implementation, any interworking carried out, where software might be obtained etc. Whatever you feel is appropriate for the WG)
regards
David
![](https://secure.gravatar.com/avatar/390e531f4f93461168de3b073b7cad07.jpg?s=120&d=mm&r=g)
Hi Valerio, On 11/20/07, Valerio Venturi <valerio.venturi@cnaf.infn.it> wrote:
Profile being implemented: OGSA Attribute Exchange Profile Organisation doing the implementation: INFN Contact details: valerio.venturi@cnaf.infn.it Short description: VOMS
Are you implementing the SAML Attribute Query Deployment Profile for X.509 Subjects or SAML Attribute Self-Query Deployment Profile for X.509 Subjects (or both)? Tom
![](https://secure.gravatar.com/avatar/25170d7bd06dd4d753053e12888d1bb0.jpg?s=120&d=mm&r=g)
Hi Valerio,
On 11/20/07, Valerio Venturi <valerio.venturi@cnaf.infn.it> wrote:
Profile being implemented: OGSA Attribute Exchange Profile Organisation doing the implementation: INFN Contact details: valerio.venturi@cnaf.infn.it Short description: VOMS
Are you implementing the SAML Attribute Query Deployment Profile for X.509 Subjects or SAML Attribute Self-Query Deployment Profile for X.509 Subjects (or both)? The Self-Query is already in place, and the other one is work in
On Fri, 2007-11-23 at 18:54 -0500, Tom Scavo wrote: progress (mainly how to authorize queries is under discussion). Related to this, I think we should add conformance targets to the profile, in the style of the OGSA Profile Defintion and WS-I Basic Profile. Do you think it would be useful? Valerio
![](https://secure.gravatar.com/avatar/390e531f4f93461168de3b073b7cad07.jpg?s=120&d=mm&r=g)
On 11/27/07, Valerio Venturi <valerio.venturi@cnaf.infn.it> wrote:
On Fri, 2007-11-23 at 18:54 -0500, Tom Scavo wrote:
Are you implementing the SAML Attribute Query Deployment Profile for X.509 Subjects or SAML Attribute Self-Query Deployment Profile for X.509 Subjects (or both)?
The Self-Query is already in place, and the other one is work in progress (mainly how to authorize queries is under discussion).
Do you provide a client in addition to a SAML AA?
Related to this, I think we should add conformance targets to the profile, in the style of the OGSA Profile Defintion and WS-I Basic Profile. Do you think it would be useful?
There already is a sentence on conformance in the OGSA Attribute Exchange Profile so I'm not sure what you mean by "conformance target." Can you give an example? Do you mean simply isolating and expanding that sentence into its own section? There is a section on conformance in the Deployment Profiles but it doesn't hurt to emphasize this in the Attribute Exchange Profile. I wouldn't introduce new terminology, however. (You'll note in the new version of the Attribute Exchange Profile I sent yesterday that I changed the terminology to agree with that in the Deployment Profiles.) Tom
![](https://secure.gravatar.com/avatar/390e531f4f93461168de3b073b7cad07.jpg?s=120&d=mm&r=g)
On 11/27/07, Tom Scavo <trscavo@gmail.com> wrote:
There is a section on conformance in the Deployment Profiles but it doesn't hurt to emphasize this in the Attribute Exchange Profile. I wouldn't introduce new terminology, however. (You'll note in the new version of the Attribute Exchange Profile I sent yesterday that I changed the terminology to agree with that in the Deployment Profiles.)
Looking at this a second time, I see that the Deployment Profiles don't go quite far enough. They introduce the terms - Extended Mode X.509 Attribute Query/Requester - Extended Mode X.509 Attribute Self-Query/Requester but we also need something like - Extended Mode X.509 Attribute Query/Responder - Extended Mode X.509 Attribute Self-Query/Responder This should be added to the Deployment Profiles but unfortunately I can't modify the document right now since it's awaiting 60-day Public Review. Speaking of which, the document has already been submitted to OASIS management for Public Review, but the process is being held up for some reason. Once it's released for Public Review, I'll announce on this list so someone can make the above comment ;-) Tom
![](https://secure.gravatar.com/avatar/390e531f4f93461168de3b073b7cad07.jpg?s=120&d=mm&r=g)
Valerio, can you provide an update on the implementation "in progress" below? How do you "authorize queries" in the case where the presenter is acting on behalf of the subject (or is this still an open question)? Thanks, Tom On Tue, Nov 27, 2007 at 4:26 AM, Valerio Venturi <valerio.venturi@cnaf.infn.it> wrote:
On Fri, 2007-11-23 at 18:54 -0500, Tom Scavo wrote:
Hi Valerio,
On 11/20/07, Valerio Venturi <valerio.venturi@cnaf.infn.it> wrote:
Profile being implemented: OGSA Attribute Exchange Profile Organisation doing the implementation: INFN Contact details: valerio.venturi@cnaf.infn.it Short description: VOMS
Are you implementing the SAML Attribute Query Deployment Profile for X.509 Subjects or SAML Attribute Self-Query Deployment Profile for X.509 Subjects (or both)?
The Self-Query is already in place, and the other one is work in progress (mainly how to authorize queries is under discussion). Related to this, I think we should add conformance targets to the profile, in the style of the OGSA Profile Defintion and WS-I Basic Profile. Do you think it would be useful?
Valerio
![](https://secure.gravatar.com/avatar/25170d7bd06dd4d753053e12888d1bb0.jpg?s=120&d=mm&r=g)
Hi Tom, sorry for the late answer, I've just got back to work. The authorization problem is still unsorted. Currently the prototype allows for specifying which subjects are allowed to query for other subjects. Given that, the protocols is in place, this when we had the demo in Boston Krzystof warn me of some flaws in my service that I haven't been able to fix yet. AFAIHU UVOS authorization should be more stable, but Krzystof can say more than me about this. I have seen that an implementation for the SAML Attribute Query for X.509 Subjects has made in as a Google Summer of Code 2008 project mentored by Globus. Keep us informed about the thing and let us know if you think that VOMS or UVOS implementations can somehow participate in the demo. Valerio On Tue, 2008-03-04 at 08:39 -0500, Tom Scavo wrote:
Valerio, can you provide an update on the implementation "in progress" below? How do you "authorize queries" in the case where the presenter is acting on behalf of the subject (or is this still an open question)?
Thanks, Tom
On Tue, Nov 27, 2007 at 4:26 AM, Valerio Venturi <valerio.venturi@cnaf.infn.it> wrote:
On Fri, 2007-11-23 at 18:54 -0500, Tom Scavo wrote:
Hi Valerio,
On 11/20/07, Valerio Venturi <valerio.venturi@cnaf.infn.it> wrote:
Profile being implemented: OGSA Attribute Exchange Profile Organisation doing the implementation: INFN Contact details: valerio.venturi@cnaf.infn.it Short description: VOMS
Are you implementing the SAML Attribute Query Deployment Profile for X.509 Subjects or SAML Attribute Self-Query Deployment Profile for X.509 Subjects (or both)?
The Self-Query is already in place, and the other one is work in progress (mainly how to authorize queries is under discussion). Related to this, I think we should add conformance targets to the profile, in the style of the OGSA Profile Defintion and WS-I Basic Profile. Do you think it would be useful?
Valerio
![](https://secure.gravatar.com/avatar/390e531f4f93461168de3b073b7cad07.jpg?s=120&d=mm&r=g)
On Fri, Mar 21, 2008 at 9:36 AM, Valerio Venturi <valerio.venturi@cnaf.infn.it> wrote:
The authorization problem is still unsorted. Currently the prototype allows for specifying which subjects are allowed to query for other subjects.
Right, you could implement something at the attribute authority (AA) that suitably restricts the set of requesters, but that doesn't solve the problem. Since the profile specifies that the name identifier in the query is a DN, there is no way to prove user presence at the Grid SP. Without proof of user presence, an SP could phish for attributes to its heart's content. Note there is no such problem for the self-query (of which traditional VOMS is an example), rather the problem involves a query where the requester is acting on behalf of the subject. In that case, the subject must pass some piece of information to the Grid SP that the SP can forward to the AA. In Shibboleth attribute query, for example, that piece of information is a transient and/or encrypted identifier. We don't have that here, and so the profile is lacking. Consequently, I'm convinced we've specified the name identifier in the query (DN) incorrectly. The requester has to prove user presence. More than a DN is needed. Since the user is authenticating to the Grid SP with an X.509 certificate, the obvious conclusion is that 1) there is some piece of info in the cert that proves user presence, and 2) the SP passes the complete cert (not just the DN) to the AA.
I have seen that an implementation for the SAML Attribute Query for X.509 Subjects has made in as a Google Summer of Code 2008 project mentored by Globus. Keep us informed about the thing and let us know if you think that VOMS or UVOS implementations can somehow participate in the demo.
Thanks, I'll do that. Tom
![](https://secure.gravatar.com/avatar/6e1526a3d8af0bb09676f1b771810cf4.jpg?s=120&d=mm&r=g)
Hi Tom I dont fully agree with your analysis since you have missed out the concept of trust. If an AA trusts an entity to act as a proxy on behalf of another entity (and this is actually the case we have here with the Grid SP acting as a proxy on behalf of the user) then the AA will be prepared to let the trusted proxy have the attributes of the entity it is acting on behalf of. There are many ways for the AA to know who it trusts. One way is for it to configure in the names of the trusted proxies (this is the easiest way but is not scalable), another is for it to configure in the name of a trusted entity that says who are trusted proxies (much more scalable since the trusted entity can authorise hundreds or thousands of trusted proxies) and for the trusted proxy to present this token to the AA. Another way would be for the user to give a token to the proxy saying that it authorises the proxy to act on its behalf, and the proxy can present this to the AA. However, this later model will require enhancements to the communications between the user and the Grid SP, which is probably a route you dont want to go down. Note that this issue is not unique to grids. Shibboleth has a similar problem of determine who are trusted IDPs, and it has solved it in the unscalable easy way by passing the complete list of trusted IDPs in the meta data. Not the best choice, but a quick and easy one. So the solution that Valerio has currently chosen is no different to the one that Shibboleth has chosen regards David Tom Scavo wrote:
On Fri, Mar 21, 2008 at 9:36 AM, Valerio Venturi <valerio.venturi@cnaf.infn.it> wrote:
The authorization problem is still unsorted. Currently the prototype allows for specifying which subjects are allowed to query for other subjects.
Right, you could implement something at the attribute authority (AA) that suitably restricts the set of requesters, but that doesn't solve the problem. Since the profile specifies that the name identifier in the query is a DN, there is no way to prove user presence at the Grid SP. Without proof of user presence, an SP could phish for attributes to its heart's content.
Note there is no such problem for the self-query (of which traditional VOMS is an example), rather the problem involves a query where the requester is acting on behalf of the subject. In that case, the subject must pass some piece of information to the Grid SP that the SP can forward to the AA. In Shibboleth attribute query, for example, that piece of information is a transient and/or encrypted identifier. We don't have that here, and so the profile is lacking.
Consequently, I'm convinced we've specified the name identifier in the query (DN) incorrectly. The requester has to prove user presence. More than a DN is needed. Since the user is authenticating to the Grid SP with an X.509 certificate, the obvious conclusion is that 1) there is some piece of info in the cert that proves user presence, and 2) the SP passes the complete cert (not just the DN) to the AA.
I have seen that an implementation for the SAML Attribute Query for X.509 Subjects has made in as a Google Summer of Code 2008 project mentored by Globus. Keep us informed about the thing and let us know if you think that VOMS or UVOS implementations can somehow participate in the demo.
Thanks, I'll do that.
Tom -- 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 *****************************************************************
![](https://secure.gravatar.com/avatar/390e531f4f93461168de3b073b7cad07.jpg?s=120&d=mm&r=g)
On Fri, Mar 21, 2008 at 6:15 PM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
I dont fully agree with your analysis since you have missed out the concept of trust. If an AA trusts an entity to act as a proxy on behalf of another entity (and this is actually the case we have here with the Grid SP acting as a proxy on behalf of the user) then the AA will be prepared to let the trusted proxy have the attributes of the entity it is acting on behalf of. There are many ways for the AA to know who it trusts. One way is for it to configure in the names of the trusted proxies (this is the easiest way but is not scalable), another is for it to configure in the name of a trusted entity that says who are trusted proxies (much more scalable since the trusted entity can authorise hundreds or thousands of trusted proxies) and for the trusted proxy to present this token to the AA.
What you say is true. If the AA trusts the requester, then we're fine of course. In the typical cross-domain scenario, however, I claim this is more trust than the AA can bear. No AA worth its salt will respond to a cold query from an SP wielding a DN, even if the SP is "trusted" in other respects.
Another way would be for the user to give a token to the proxy saying that it authorises the proxy to act on its behalf, and the proxy can present this to the AA.
Yes, this approach will work, in general. It is the approach I'm advocating, in fact.
However, this later model will require enhancements to the communications between the user and the Grid SP, which is probably a route you dont want to go down.
Having adopted a push model, our project is already far down this path (and making more progress than we ever did with a pull model, I might add). (In fact, sometimes I wonder if it's worth belaboring the pull model further.)
Note that this issue is not unique to grids. Shibboleth has a similar problem of determine who are trusted IDPs, and it has solved it in the unscalable easy way by passing the complete list of trusted IDPs in the meta data. Not the best choice, but a quick and easy one. So the solution that Valerio has currently chosen is no different to the one that Shibboleth has chosen
No, that's not the whole story, I'm afraid. In fact, metadata has nothing to do with user presence. The Shib SP queries the AA using a transient, encrypted name identifier that the *user* obtained from the IdP during the SSO step. By presenting this identifier to the AA, the SP proves user presence. If you take away the SSO step and replace the Shib SP by a Grid SP, you have precisely the use case that our profile addresses. But by taking away the SSO step, you lose the transient name identifier, so the Grid SP is unable to prove user presence. No Shib AA will respond to such a query. I doubt I've convinced you, but I've made my point the best I can, so I won't try to convince you further :-) Let me close by proposing the following "patch" to our profile: Instead of *requiring* a DN, the name identifier in the query should be generalized to accommodate the entire certificate (without excluding the possibility of a naked DN in those situations where it is warranted). This can be done using <ds:KeyInfo>, something like this: <saml:Subject> <saml:BaseID xsi:type="KeyIdentifierType"> <ds:KeyInfo>...</ds:KeyInfo> </saml:BaseID> </saml:Subject> where KeyIdentifierType is defined as follows: <complexType name="KeyIdentifierType"> <complexContent> <extension base="saml:BaseIDAbstractType"> <sequence> <element ref="ds:KeyInfo"/> </sequence> </extension> </complexContent> </complexType> This new name identifier type accommodates either a DN or a certificate. In addition to proving user presence at the Grid SP, using a certificate in this way has the extra added benefit that it avoids potential DN string matching at the AA, which in and of itself is almost sufficient reason to pass a certificate instead of a DN. Tom
![](https://secure.gravatar.com/avatar/6e1526a3d8af0bb09676f1b771810cf4.jpg?s=120&d=mm&r=g)
Hi Tom I would like to make two points to your comments Firstly you are missing the point I made about the Shibboleth metadata. This is telling the SPs which IDPs it can trust. Without this necessary information user presence is not provable, since an untrusted IDP will lie to the SP that the user has just authenticated correctly, when there could be no user or the wrong user there. Consequently the meta data is providing the trust anchors in just the same way that Valerio is doing in his list of Grid SPs. Hence my analogy on the way of providing trust is correct. Secondly the inclusion of a "certificate" needs more elaboration. The inclusion for example of a user's public key certificate proves nothing more than the presence of a DN does, since it is publicly available and an untrustworth grid SP could send any PKC it wished, just as it can send any DN it wished. Therefore one needs to specify the properties of the certificate that are being transferred, which is, that the user is delegating to the grid SP to act on its behalf. A proxy certificate would do this, as would an attribute certificate. Finally, if you have followed a lot of the (old) discussions on the PKIX list about DN matching in certificates, you will see that a lot of PKI software vendors do plain string matching of DNs, rather than proper X.500/LDAP DN matching rules, so dont believe that passing certs instead of DNs will solve this problem. It wont. Only proper DN matching software will solve this, so it is irrelevant whether the DN is passed as a string or in a cert. regards David Tom Scavo wrote:
On Fri, Mar 21, 2008 at 6:15 PM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
I dont fully agree with your analysis since you have missed out the concept of trust. If an AA trusts an entity to act as a proxy on behalf of another entity (and this is actually the case we have here with the Grid SP acting as a proxy on behalf of the user) then the AA will be prepared to let the trusted proxy have the attributes of the entity it is acting on behalf of. There are many ways for the AA to know who it trusts. One way is for it to configure in the names of the trusted proxies (this is the easiest way but is not scalable), another is for it to configure in the name of a trusted entity that says who are trusted proxies (much more scalable since the trusted entity can authorise hundreds or thousands of trusted proxies) and for the trusted proxy to present this token to the AA.
What you say is true. If the AA trusts the requester, then we're fine of course. In the typical cross-domain scenario, however, I claim this is more trust than the AA can bear. No AA worth its salt will respond to a cold query from an SP wielding a DN, even if the SP is "trusted" in other respects.
Another way would be for the user to give a token to the proxy saying that it authorises the proxy to act on its behalf, and the proxy can present this to the AA.
Yes, this approach will work, in general. It is the approach I'm advocating, in fact.
However, this later model will require enhancements to the communications between the user and the Grid SP, which is probably a route you dont want to go down.
Having adopted a push model, our project is already far down this path (and making more progress than we ever did with a pull model, I might add). (In fact, sometimes I wonder if it's worth belaboring the pull model further.)
Note that this issue is not unique to grids. Shibboleth has a similar problem of determine who are trusted IDPs, and it has solved it in the unscalable easy way by passing the complete list of trusted IDPs in the meta data. Not the best choice, but a quick and easy one. So the solution that Valerio has currently chosen is no different to the one that Shibboleth has chosen
No, that's not the whole story, I'm afraid. In fact, metadata has nothing to do with user presence. The Shib SP queries the AA using a transient, encrypted name identifier that the *user* obtained from the IdP during the SSO step. By presenting this identifier to the AA, the SP proves user presence.
If you take away the SSO step and replace the Shib SP by a Grid SP, you have precisely the use case that our profile addresses. But by taking away the SSO step, you lose the transient name identifier, so the Grid SP is unable to prove user presence. No Shib AA will respond to such a query.
I doubt I've convinced you, but I've made my point the best I can, so I won't try to convince you further :-) Let me close by proposing the following "patch" to our profile:
Instead of *requiring* a DN, the name identifier in the query should be generalized to accommodate the entire certificate (without excluding the possibility of a naked DN in those situations where it is warranted). This can be done using <ds:KeyInfo>, something like this:
<saml:Subject> <saml:BaseID xsi:type="KeyIdentifierType"> <ds:KeyInfo>...</ds:KeyInfo> </saml:BaseID> </saml:Subject>
where KeyIdentifierType is defined as follows:
<complexType name="KeyIdentifierType"> <complexContent> <extension base="saml:BaseIDAbstractType"> <sequence> <element ref="ds:KeyInfo"/> </sequence> </extension> </complexContent> </complexType>
This new name identifier type accommodates either a DN or a certificate. In addition to proving user presence at the Grid SP, using a certificate in this way has the extra added benefit that it avoids potential DN string matching at the AA, which in and of itself is almost sufficient reason to pass a certificate instead of a DN.
Tom
-- ***************************************************************** 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 *****************************************************************
![](https://secure.gravatar.com/avatar/390e531f4f93461168de3b073b7cad07.jpg?s=120&d=mm&r=g)
On Sat, Mar 22, 2008 at 5:44 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
...the inclusion of a "certificate" needs more elaboration. The inclusion for example of a user's public key certificate proves nothing more than the presence of a DN does, since it is publicly available and an untrustworth grid SP could send any PKC it wished, just as it can send any DN it wished. Therefore one needs to specify the properties of the certificate that are being transferred, which is, that the user is delegating to the grid SP to act on its behalf. A proxy certificate would do this, as would an attribute certificate.
I totally agree. Of course this requires a new attribute request handler at the Shib AA but then a new handler is required for a bare DN as well, so there's no additional penalty. I don't know that much about the VOMS AA, but I'd be surprised if handling a full certificate turned out to be much of a problem for VOMS. We have a dilemma, however. A formal ballot is currently underway to promote the OASIS SAML V2.0 Deployment Profiles for X.509 Subjects to Committee Specification status. I fully expect this ballot to succeed. The next step after Committee Specification is OASIS Standard (but this last step requires three attestations, which is unlikely). If we introduce a normative change to the profile such as we've been discussing, we essentially start over. Presumably the profile could travel faster through committee this time around since the bulk of it has already been vetted, but a significant delay is inevitable. The other alternative is to specify this new extension of saml2:BaseIDAbstractType in our Attribute Exchange profile and leave the OASIS profile alone, flawed as it is. A third alternative is to do nothing. I'm not sure what to recommend. I'll let others comment on the appropriate course of action. Tom
Tom Scavo wrote:
Instead of *requiring* a DN, the name identifier in the query should be generalized to accommodate the entire certificate (without excluding the possibility of a naked DN in those situations where it is warranted). This can be done using <ds:KeyInfo>, something like this:
<saml:Subject> <saml:BaseID xsi:type="KeyIdentifierType"> <ds:KeyInfo>...</ds:KeyInfo> </saml:BaseID> </saml:Subject>
where KeyIdentifierType is defined as follows:
<complexType name="KeyIdentifierType"> <complexContent> <extension base="saml:BaseIDAbstractType"> <sequence> <element ref="ds:KeyInfo"/> </sequence> </extension> </complexContent> </complexType>
![](https://secure.gravatar.com/avatar/6e1526a3d8af0bb09676f1b771810cf4.jpg?s=120&d=mm&r=g)
Hi Tom we do a dis-service to people by specifying a standard which we know to be deficient beforehand. This will cause even more delays in trying to rectify it (consider for example the OGSA Authz SAML spec, GFD 66, which was only found to be deficient after practical trials, and how long it has taken to produce replacements). My suggestion would be to raise a ballot comment now on the current OASIS draft, along with a proposed solution, so that this can be taken into account in the revision. If the process is anything like IETF or ISO it should not cause too much of a delay. regards David Tom Scavo wrote:
On Sat, Mar 22, 2008 at 5:44 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
...the inclusion of a "certificate" needs more elaboration. The inclusion for example of a user's public key certificate proves nothing more than the presence of a DN does, since it is publicly available and an untrustworth grid SP could send any PKC it wished, just as it can send any DN it wished. Therefore one needs to specify the properties of the certificate that are being transferred, which is, that the user is delegating to the grid SP to act on its behalf. A proxy certificate would do this, as would an attribute certificate.
I totally agree. Of course this requires a new attribute request handler at the Shib AA but then a new handler is required for a bare DN as well, so there's no additional penalty. I don't know that much about the VOMS AA, but I'd be surprised if handling a full certificate turned out to be much of a problem for VOMS.
We have a dilemma, however. A formal ballot is currently underway to promote the OASIS SAML V2.0 Deployment Profiles for X.509 Subjects to Committee Specification status. I fully expect this ballot to succeed. The next step after Committee Specification is OASIS Standard (but this last step requires three attestations, which is unlikely).
If we introduce a normative change to the profile such as we've been discussing, we essentially start over. Presumably the profile could travel faster through committee this time around since the bulk of it has already been vetted, but a significant delay is inevitable.
The other alternative is to specify this new extension of saml2:BaseIDAbstractType in our Attribute Exchange profile and leave the OASIS profile alone, flawed as it is. A third alternative is to do nothing.
I'm not sure what to recommend. I'll let others comment on the appropriate course of action.
Tom
Tom Scavo wrote:
Instead of *requiring* a DN, the name identifier in the query should be generalized to accommodate the entire certificate (without excluding the possibility of a naked DN in those situations where it is warranted). This can be done using <ds:KeyInfo>, something like this:
<saml:Subject> <saml:BaseID xsi:type="KeyIdentifierType"> <ds:KeyInfo>...</ds:KeyInfo> </saml:BaseID> </saml:Subject>
where KeyIdentifierType is defined as follows:
<complexType name="KeyIdentifierType"> <complexContent> <extension base="saml:BaseIDAbstractType"> <sequence> <element ref="ds:KeyInfo"/> </sequence> </extension> </complexContent> </complexType>
-- ***************************************************************** 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 *****************************************************************
![](https://secure.gravatar.com/avatar/390e531f4f93461168de3b073b7cad07.jpg?s=120&d=mm&r=g)
On Sat, Mar 22, 2008 at 11:32 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
we do a dis-service to people by specifying a standard which we know to be deficient beforehand. This will cause even more delays in trying to rectify it (consider for example the OGSA Authz SAML spec, GFD 66, which was only found to be deficient after practical trials, and how long it has taken to produce replacements).
I suppose that is why the OASIS process requires three attestations (i.e., claims of successful implementation) before OASIS Standard status can be put to the vote.
My suggestion would be to raise a ballot comment now on the current OASIS draft, along with a proposed solution, so that this can be taken into account in the revision.
I tend to agree (reluctantly). What do others think? Should the proposed solution require a <ds:KeyInfo> element and disallow an X509SubjectName identifier, or should it be more lax? That's really a tough call, I think.
If the process is anything like IETF or ISO it should not cause too much of a delay.
Such a change requires that we start from scratch, including another 60-day public review. The delay will be substantial.
Tom Scavo wrote:
On Sat, Mar 22, 2008 at 5:44 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
...the inclusion of a "certificate" needs more elaboration. The inclusion for example of a user's public key certificate proves nothing more than the presence of a DN does, since it is publicly available and an untrustworth grid SP could send any PKC it wished, just as it can send any DN it wished. Therefore one needs to specify the properties of the certificate that are being transferred, which is, that the user is delegating to the grid SP to act on its behalf. A proxy certificate would do this, as would an attribute certificate.
I totally agree. Of course this requires a new attribute request handler at the Shib AA but then a new handler is required for a bare DN as well, so there's no additional penalty. I don't know that much about the VOMS AA, but I'd be surprised if handling a full certificate turned out to be much of a problem for VOMS.
We have a dilemma, however. A formal ballot is currently underway to promote the OASIS SAML V2.0 Deployment Profiles for X.509 Subjects to Committee Specification status. I fully expect this ballot to succeed. The next step after Committee Specification is OASIS Standard (but this last step requires three attestations, which is unlikely).
If we introduce a normative change to the profile such as we've been discussing, we essentially start over. Presumably the profile could travel faster through committee this time around since the bulk of it has already been vetted, but a significant delay is inevitable.
The other alternative is to specify this new extension of saml2:BaseIDAbstractType in our Attribute Exchange profile and leave the OASIS profile alone, flawed as it is. A third alternative is to do nothing.
I'm not sure what to recommend. I'll let others comment on the appropriate course of action.
Tom
Tom Scavo wrote:
Instead of *requiring* a DN, the name identifier in the query should be generalized to accommodate the entire certificate (without excluding the possibility of a naked DN in those situations where it is warranted). This can be done using <ds:KeyInfo>, something like this:
<saml:Subject> <saml:BaseID xsi:type="KeyIdentifierType"> <ds:KeyInfo>...</ds:KeyInfo> </saml:BaseID> </saml:Subject>
where KeyIdentifierType is defined as follows:
<complexType name="KeyIdentifierType"> <complexContent> <extension base="saml:BaseIDAbstractType"> <sequence> <element ref="ds:KeyInfo"/> </sequence> </extension> </complexContent> </complexType>
--
***************************************************************** 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
*****************************************************************
![](https://secure.gravatar.com/avatar/6e1526a3d8af0bb09676f1b771810cf4.jpg?s=120&d=mm&r=g)
Hi Tom thanks for taking the painful but necessary step of raising a defect. Actually I dont think it is as bad as you say. The current draft is not erroneous, it is simply lacking in a non-essential though useful feature. The DN is not erroneous. It is perfectly OK and I would not suggest removing it. The reasons have already been given in my earlier discussions on Trust i.e. if the AA trusts the Grid SP then the DN of the Grid SP in the caller field (sorry may not have used the correct term here) and the DN of the user in the subject field (again may not be correct term) is sufficient to provide a perfectly good proxy service. It is also as scalable as Shibboleth is today (cf the metadata). So what you are proposing to add is a feature that will allow greater scalability and less configuring of trust meta data, since the user can dynamically delegate to a proxy to request attributes on his behalf. This is a nice additional feature to the current draft, but is not a show stopper in my opinion Regards David Tom Scavo wrote:
On Sat, Mar 22, 2008 at 11:32 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
we do a dis-service to people by specifying a standard which we know to be deficient beforehand. This will cause even more delays in trying to rectify it (consider for example the OGSA Authz SAML spec, GFD 66, which was only found to be deficient after practical trials, and how long it has taken to produce replacements).
I suppose that is why the OASIS process requires three attestations (i.e., claims of successful implementation) before OASIS Standard status can be put to the vote.
My suggestion would be to raise a ballot comment now on the current OASIS draft, along with a proposed solution, so that this can be taken into account in the revision.
I tend to agree (reluctantly). What do others think?
Should the proposed solution require a <ds:KeyInfo> element and disallow an X509SubjectName identifier, or should it be more lax? That's really a tough call, I think.
If the process is anything like IETF or ISO it should not cause too much of a delay.
Such a change requires that we start from scratch, including another 60-day public review. The delay will be substantial.
Tom Scavo wrote:
On Sat, Mar 22, 2008 at 5:44 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
...the inclusion of a "certificate" needs more elaboration. The inclusion for example of a user's public key certificate proves nothing more than the presence of a DN does, since it is publicly available and an untrustworth grid SP could send any PKC it wished, just as it can send any DN it wished. Therefore one needs to specify the properties of the certificate that are being transferred, which is, that the user is delegating to the grid SP to act on its behalf. A proxy certificate would do this, as would an attribute certificate.
I totally agree. Of course this requires a new attribute request handler at the Shib AA but then a new handler is required for a bare DN as well, so there's no additional penalty. I don't know that much about the VOMS AA, but I'd be surprised if handling a full certificate turned out to be much of a problem for VOMS.
We have a dilemma, however. A formal ballot is currently underway to promote the OASIS SAML V2.0 Deployment Profiles for X.509 Subjects to Committee Specification status. I fully expect this ballot to succeed. The next step after Committee Specification is OASIS Standard (but this last step requires three attestations, which is unlikely).
If we introduce a normative change to the profile such as we've been discussing, we essentially start over. Presumably the profile could travel faster through committee this time around since the bulk of it has already been vetted, but a significant delay is inevitable.
The other alternative is to specify this new extension of saml2:BaseIDAbstractType in our Attribute Exchange profile and leave the OASIS profile alone, flawed as it is. A third alternative is to do nothing.
I'm not sure what to recommend. I'll let others comment on the appropriate course of action.
Tom
Tom Scavo wrote:
Instead of *requiring* a DN, the name identifier in the query should be generalized to accommodate the entire certificate (without excluding the possibility of a naked DN in those situations where it is warranted). This can be done using <ds:KeyInfo>, something like this:
<saml:Subject> <saml:BaseID xsi:type="KeyIdentifierType"> <ds:KeyInfo>...</ds:KeyInfo> </saml:BaseID> </saml:Subject>
where KeyIdentifierType is defined as follows:
<complexType name="KeyIdentifierType"> <complexContent> <extension base="saml:BaseIDAbstractType"> <sequence> <element ref="ds:KeyInfo"/> </sequence> </extension> </complexContent> </complexType>
--
***************************************************************** 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 *****************************************************************
![](https://secure.gravatar.com/avatar/390e531f4f93461168de3b073b7cad07.jpg?s=120&d=mm&r=g)
I appreciate your suggestions and opinions, David, but I'm still confused. If we accept there is a defect and agree that passing a certificate mitigates the defect, there are two questions remaining: 1. Do we apply the patch to the OASIS profile or the OGSA profile? 2. What normative language should be used when discussing requirements regarding the SAML subject? On the one hand, you suggest patching the OASIS profile, but on the other hand, you classify the defect as merely a "nice feature," which implies to me we could apply the patch to the OGSA profile without much problem. Do you still recommend patching the OASIS profile? FYI, currently in the OASIS profile we say that X509SubjectName MUST be used, and moreover, the DN MUST conform to RFC 2253. The latter is somewhat problematic since SAML Core does not go so far as to mandate RFC 2253. (I put that in to assist with DN string comparisons.) Thus the OASIS profile essentially extends SAML Core with respect to X509SubjectName identifiers. (That never felt quite right, but nobody questioned it so I let it slide.) If we decide to add this new extension of saml2:BaseIDAbstractType to the OASIS profile, then I suggest we remove the RFC 2253 requirement on the standard X509SubjectName identifier and add an RFC 2253 requirement to <ds:KeyInfo>. That is, if the SP uses <ds:KeyInfo> to pass a DN, that DN MUST conform to RFC 2253. Now this has a ripple effect on the OASIS profile. In particular, the metadata schema change proposed in section 3.8.1 can be removed because the need for it no longer exists (as stated, anyway). So altogether this is not a trivial modification of the profile. More importantly, it's not clear to me what normative language should be used when describing the SAML subject. I think a conforming IdP MUST support both X509SubjectName and the extension of saml2:BaseIDAbstractType, but the SP is free to use whatever it wants. I dare say this suggests that all of section 2 can be eliminated. So, no, this is not a cosmetic change. It will require a complete rewrite and we are back to square one. I guess I don't mind doing it, but I'll wait and see what others think. Tom On Sat, Mar 22, 2008 at 12:49 PM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Hi Tom
thanks for taking the painful but necessary step of raising a defect.
Actually I dont think it is as bad as you say. The current draft is not erroneous, it is simply lacking in a non-essential though useful feature. The DN is not erroneous. It is perfectly OK and I would not suggest removing it. The reasons have already been given in my earlier discussions on Trust i.e. if the AA trusts the Grid SP then the DN of the Grid SP in the caller field (sorry may not have used the correct term here) and the DN of the user in the subject field (again may not be correct term) is sufficient to provide a perfectly good proxy service. It is also as scalable as Shibboleth is today (cf the metadata). So what you are proposing to add is a feature that will allow greater scalability and less configuring of trust meta data, since the user can dynamically delegate to a proxy to request attributes on his behalf. This is a nice additional feature to the current draft, but is not a show stopper in my opinion
Regards
David
Tom Scavo wrote:
On Sat, Mar 22, 2008 at 11:32 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
we do a dis-service to people by specifying a standard which we know to be deficient beforehand. This will cause even more delays in trying to rectify it (consider for example the OGSA Authz SAML spec, GFD 66, which was only found to be deficient after practical trials, and how long it has taken to produce replacements).
I suppose that is why the OASIS process requires three attestations (i.e., claims of successful implementation) before OASIS Standard status can be put to the vote.
My suggestion would be to raise a ballot comment now on the current OASIS draft, along with a proposed solution, so that this can be taken into account in the revision.
I tend to agree (reluctantly). What do others think?
Should the proposed solution require a <ds:KeyInfo> element and disallow an X509SubjectName identifier, or should it be more lax? That's really a tough call, I think.
If the process is anything like IETF or ISO it should not cause too much of a delay.
Such a change requires that we start from scratch, including another 60-day public review. The delay will be substantial.
Tom Scavo wrote:
On Sat, Mar 22, 2008 at 5:44 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
...the inclusion of a "certificate" needs more elaboration. The inclusion for example of a user's public key certificate proves nothing more than the presence of a DN does, since it is publicly available and an untrustworth grid SP could send any PKC it wished, just as it can send any DN it wished. Therefore one needs to specify the properties of the certificate that are being transferred, which is, that the user is delegating to the grid SP to act on its behalf. A proxy certificate would do this, as would an attribute certificate.
I totally agree. Of course this requires a new attribute request handler at the Shib AA but then a new handler is required for a bare DN as well, so there's no additional penalty. I don't know that much about the VOMS AA, but I'd be surprised if handling a full certificate turned out to be much of a problem for VOMS.
We have a dilemma, however. A formal ballot is currently underway to promote the OASIS SAML V2.0 Deployment Profiles for X.509 Subjects to Committee Specification status. I fully expect this ballot to succeed. The next step after Committee Specification is OASIS Standard (but this last step requires three attestations, which is unlikely).
If we introduce a normative change to the profile such as we've been discussing, we essentially start over. Presumably the profile could travel faster through committee this time around since the bulk of it has already been vetted, but a significant delay is inevitable.
The other alternative is to specify this new extension of saml2:BaseIDAbstractType in our Attribute Exchange profile and leave the OASIS profile alone, flawed as it is. A third alternative is to do nothing.
I'm not sure what to recommend. I'll let others comment on the appropriate course of action.
Tom
Tom Scavo wrote:
Instead of *requiring* a DN, the name identifier in the query should be generalized to accommodate the entire certificate (without excluding the possibility of a naked DN in those situations where it is warranted). This can be done using <ds:KeyInfo>, something like this:
<saml:Subject> <saml:BaseID xsi:type="KeyIdentifierType"> <ds:KeyInfo>...</ds:KeyInfo> </saml:BaseID> </saml:Subject>
where KeyIdentifierType is defined as follows:
<complexType name="KeyIdentifierType"> <complexContent> <extension base="saml:BaseIDAbstractType"> <sequence> <element ref="ds:KeyInfo"/> </sequence> </extension> </complexContent> </complexType>
--
***************************************************************** 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
*****************************************************************
![](https://secure.gravatar.com/avatar/6e1526a3d8af0bb09676f1b771810cf4.jpg?s=120&d=mm&r=g)
Hi Tom Defects can be of three types (at least). Bug/Broken, meaning that the standard does not work; Off specification, meaning that the standard works but does not conform to what is really required; and Enhancement, meaning that an additional feature is required to be added to the standard. I was originally suggesting that the defect we are discussing is of the later type, meaning that the current standard works and is what is required for many use cases, but does not cover all use cases (however see my last point below). So the issues are a) how does OASIS handle enhancements? Can they be rapidly applied or not? b) does the OASIS group agree that this enhancement is worthy of adding in the first place. ISO/ITU-T and IETF can handle minor enhancements to their (draft) standards without causing any delay to the publishing cycle. I dont know if OASIS can do this or not, but if they can this would be my preferred route given that b) is accepted by the OASIS group. On the issue of whether the enhancement should be applied to the OASIS spec or the OGSA spec, this hinges on issue b) above. If the OASIS group accept it as a valid and needed enhancement then I would suggest adding it to the OASIS specification. If the OASIS group do not accept it as a needed enhancement, or it is decided that the enhancement will impact too much on the publishing cycle of the OASIS standard, then it would be better to fix it in the OGSA standard since this change should not significantly impact on the publishing cycle of the OGF document. You seem to imply that the latter is the case since the number of changes are quite significant. Concerning the specific syntax of the change see my comments inline below. I have read your spec again and have the following queries to make. i)Section 3.9.3 says "an identity provider SHOULD check the lifetime of the referenced certificate before issuing an assertion regarding an X.509 Subject. If the certificate has expired, an error should be returned. As a further privacy measure, the principal may use a short-lived X.509 identity certificate. For example, an X.509 proxy certificate [RFC3820]) may be used." Questions: 1. How is the subject's current X.509 certificate identified by the SP to the IDP? The protocol does not seem to carry this as currently specified. 2. Is the IDP supposed to pull the subject's X.509 PKC from somewhere before replying to the SP's request? I think section 3.10.2 is a very weak response to this problem and merely punts the issue onto the IDP. 3. How does the IDP know that the subject has used a proxy certificate to contact the SP, and if so, how does the IDP get hold of this to verify its validity time? It seems to me that your current spec might actually be broken in respects of the proxy certificate and therefore need fixing before it is published. The enhancement we are discussing can actually be a fix for this bug. Tom Scavo wrote:
I appreciate your suggestions and opinions, David, but I'm still confused. If we accept there is a defect and agree that passing a certificate mitigates the defect, there are two questions remaining:
1. Do we apply the patch to the OASIS profile or the OGSA profile?
2. What normative language should be used when discussing requirements regarding the SAML subject?
On the one hand, you suggest patching the OASIS profile, but on the other hand, you classify the defect as merely a "nice feature," which implies to me we could apply the patch to the OGSA profile without much problem. Do you still recommend patching the OASIS profile?
FYI, currently in the OASIS profile we say that X509SubjectName MUST be used, and moreover, the DN MUST conform to RFC 2253. The latter is somewhat problematic since SAML Core does not go so far as to mandate RFC 2253. (I put that in to assist with DN string comparisons.)
this is a good idea. However it is the matching rule that is really important. Does your statement go far enough to cover matching rules or not? Thus
the OASIS profile essentially extends SAML Core with respect to X509SubjectName identifiers. (That never felt quite right, but nobody questioned it so I let it slide.)
If we decide to add this new extension of saml2:BaseIDAbstractType to the OASIS profile, then I suggest we remove the RFC 2253 requirement on the standard X509SubjectName identifier and add an RFC 2253 requirement to <ds:KeyInfo>.
this is not actually needed since it is already in section 4.4.4 of RFC 3275 That is, if the SP uses <ds:KeyInfo> to
pass a DN, that DN MUST conform to RFC 2253.
Now this has a ripple effect on the OASIS profile. In particular, the metadata schema change proposed in section 3.8.1 can be removed because the need for it no longer exists (as stated, anyway). So altogether this is not a trivial modification of the profile.
agreed, because keyInfo has lots of optional elements and you will need to say which can be used and which cannot. Also, and more importantly, keyInfo says NOTHING about using proxy certificates or attribute certificates, and something like this is needed for delegation from the user to the SP. So it quite a bit of work to add this.
More importantly, it's not clear to me what normative language should be used when describing the SAML subject. I think a conforming IdP MUST support both X509SubjectName and the extension of saml2:BaseIDAbstractType, but the SP is free to use whatever it wants. I dare say this suggests that all of section 2 can be eliminated.
I agree.
So, no, this is not a cosmetic change. It will require a complete rewrite and we are back to square one. I guess I don't mind doing it, but I'll wait and see what others think.
Yes, but I suggest that the current spec might be broken anyway, in which case an update is needed anyway regards David
Tom
On Sat, Mar 22, 2008 at 12:49 PM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Hi Tom
thanks for taking the painful but necessary step of raising a defect.
Actually I dont think it is as bad as you say. The current draft is not erroneous, it is simply lacking in a non-essential though useful feature. The DN is not erroneous. It is perfectly OK and I would not suggest removing it. The reasons have already been given in my earlier discussions on Trust i.e. if the AA trusts the Grid SP then the DN of the Grid SP in the caller field (sorry may not have used the correct term here) and the DN of the user in the subject field (again may not be correct term) is sufficient to provide a perfectly good proxy service. It is also as scalable as Shibboleth is today (cf the metadata). So what you are proposing to add is a feature that will allow greater scalability and less configuring of trust meta data, since the user can dynamically delegate to a proxy to request attributes on his behalf. This is a nice additional feature to the current draft, but is not a show stopper in my opinion
Regards
David
Tom Scavo wrote:
On Sat, Mar 22, 2008 at 11:32 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
we do a dis-service to people by specifying a standard which we know to be deficient beforehand. This will cause even more delays in trying to rectify it (consider for example the OGSA Authz SAML spec, GFD 66, which was only found to be deficient after practical trials, and how long it has taken to produce replacements).
I suppose that is why the OASIS process requires three attestations (i.e., claims of successful implementation) before OASIS Standard status can be put to the vote.
My suggestion would be to raise a ballot comment now on the current OASIS draft, along with a proposed solution, so that this can be taken into account in the revision.
I tend to agree (reluctantly). What do others think?
Should the proposed solution require a <ds:KeyInfo> element and disallow an X509SubjectName identifier, or should it be more lax? That's really a tough call, I think.
If the process is anything like IETF or ISO it should not cause too much of a delay.
Such a change requires that we start from scratch, including another 60-day public review. The delay will be substantial.
Tom Scavo wrote:
On Sat, Mar 22, 2008 at 5:44 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
...the inclusion of a "certificate" needs more elaboration. The inclusion for example of a user's public key certificate proves nothing more than the presence of a DN does, since it is publicly available and an untrustworth grid SP could send any PKC it wished, just as it can send any DN it wished. Therefore one needs to specify the properties of the certificate that are being transferred, which is, that the user is delegating to the grid SP to act on its behalf. A proxy certificate would do this, as would an attribute certificate.
I totally agree. Of course this requires a new attribute request handler at the Shib AA but then a new handler is required for a bare DN as well, so there's no additional penalty. I don't know that much about the VOMS AA, but I'd be surprised if handling a full certificate turned out to be much of a problem for VOMS.
We have a dilemma, however. A formal ballot is currently underway to promote the OASIS SAML V2.0 Deployment Profiles for X.509 Subjects to Committee Specification status. I fully expect this ballot to succeed. The next step after Committee Specification is OASIS Standard (but this last step requires three attestations, which is unlikely).
If we introduce a normative change to the profile such as we've been discussing, we essentially start over. Presumably the profile could travel faster through committee this time around since the bulk of it has already been vetted, but a significant delay is inevitable.
The other alternative is to specify this new extension of saml2:BaseIDAbstractType in our Attribute Exchange profile and leave the OASIS profile alone, flawed as it is. A third alternative is to do nothing.
I'm not sure what to recommend. I'll let others comment on the appropriate course of action.
Tom
Tom Scavo wrote: > > Instead of *requiring* a DN, the name identifier in the query should > be generalized to accommodate the entire certificate (without > excluding the possibility of a naked DN in those situations where it > is warranted). This can be done using <ds:KeyInfo>, something like > this: > > <saml:Subject> > <saml:BaseID xsi:type="KeyIdentifierType"> > <ds:KeyInfo>...</ds:KeyInfo> > </saml:BaseID> > </saml:Subject> > > where KeyIdentifierType is defined as follows: > > <complexType name="KeyIdentifierType"> > <complexContent> > <extension base="saml:BaseIDAbstractType"> > <sequence> > <element ref="ds:KeyInfo"/> > </sequence> > </extension> > </complexContent> > </complexType>
--
***************************************************************** 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 *****************************************************************
![](https://secure.gravatar.com/avatar/390e531f4f93461168de3b073b7cad07.jpg?s=120&d=mm&r=g)
Hi David, Sorry for the delay. Please find some remarks inline. On Sun, Mar 23, 2008 at 4:27 PM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Defects can be of three types (at least). Bug/Broken, meaning that the standard does not work; Off specification, meaning that the standard works but does not conform to what is really required; and Enhancement, meaning that an additional feature is required to be added to the standard. I was originally suggesting that the defect we are discussing is of the later type, meaning that the current standard works and is what is required for many use cases, but does not cover all use cases (however see my last point below).
So the issues are a) how does OASIS handle enhancements? Can they be rapidly applied or not?
OASIS specifications have "Errata" associated with them. Errata are non-normative changes to an OASIS Standard, usually wording changes or other clarifications.
b) does the OASIS group agree that this enhancement is worthy of adding in the first place.
I haven't asked and I don't think it matters. If I make a normative change to the document (which is what we're talking about here), we go back to square one. (See other thread on OASIS process.)
ISO/ITU-T and IETF can handle minor enhancements to their (draft) standards without causing any delay to the publishing cycle. I dont know if OASIS can do this or not, but if they can this would be my preferred route given that b) is accepted by the OASIS group.
On the issue of whether the enhancement should be applied to the OASIS spec or the OGSA spec, this hinges on issue b) above. If the OASIS group accept it as a valid and needed enhancement then I would suggest adding it to the OASIS specification. If the OASIS group do not accept it as a needed enhancement, or it is decided that the enhancement will impact too much on the publishing cycle of the OASIS standard, then it would be better to fix it in the OGSA standard since this change should not significantly impact on the publishing cycle of the OGF document. You seem to imply that the latter is the case since the number of changes are quite significant.
Yes, the spec is brittle insofar as this single change will have a ripple effect throughout the entire document. Just to let you know, regardless of what the AuthZ-WG decides to do, I intend to rewrite the OASIS document. I'm not sure how quickly I can get this done, but in any event, since another 60-day Public Review would be required, the time lag would be significant.
Concerning the specific syntax of the change see my comments inline below.
I have read your spec again and have the following queries to make.
i)Section 3.9.3 says "an identity provider SHOULD check the lifetime of the referenced certificate before issuing an assertion regarding an X.509 Subject. If the certificate has expired, an error should be returned. As a further privacy measure, the principal may use a short-lived X.509 identity certificate. For example, an X.509 proxy certificate [RFC3820]) may be used."
Questions: 1. How is the subject's current X.509 certificate identified by the SP to the IDP? The protocol does not seem to carry this as currently specified.
You're right, it doesn't.
2. Is the IDP supposed to pull the subject's X.509 PKC from somewhere before replying to the SP's request? I think section 3.10.2 is a very weak response to this problem and merely punts the issue onto the IDP.
Exactly how the IdP accesses the subject's X.509 certificate is out of scope.
3. How does the IDP know that the subject has used a proxy certificate to contact the SP, and if so, how does the IDP get hold of this to verify its validity time?
Good question.
It seems to me that your current spec might actually be broken in respects of the proxy certificate and therefore need fixing before it is published. The enhancement we are discussing can actually be a fix for this bug.
You are absolutely correct. (I wish you had pointed this out during the 60-day Public Review, but oh well :) Tom
Tom Scavo wrote:
I appreciate your suggestions and opinions, David, but I'm still confused. If we accept there is a defect and agree that passing a certificate mitigates the defect, there are two questions remaining:
1. Do we apply the patch to the OASIS profile or the OGSA profile?
2. What normative language should be used when discussing requirements regarding the SAML subject?
On the one hand, you suggest patching the OASIS profile, but on the other hand, you classify the defect as merely a "nice feature," which implies to me we could apply the patch to the OGSA profile without much problem. Do you still recommend patching the OASIS profile?
FYI, currently in the OASIS profile we say that X509SubjectName MUST be used, and moreover, the DN MUST conform to RFC 2253. The latter is somewhat problematic since SAML Core does not go so far as to mandate RFC 2253. (I put that in to assist with DN string comparisons.)
this is a good idea. However it is the matching rule that is really important. Does your statement go far enough to cover matching rules or not?
Thus
the OASIS profile essentially extends SAML Core with respect to X509SubjectName identifiers. (That never felt quite right, but nobody questioned it so I let it slide.)
If we decide to add this new extension of saml2:BaseIDAbstractType to the OASIS profile, then I suggest we remove the RFC 2253 requirement on the standard X509SubjectName identifier and add an RFC 2253 requirement to <ds:KeyInfo>.
this is not actually needed since it is already in section 4.4.4 of RFC 3275
That is, if the SP uses <ds:KeyInfo> to
pass a DN, that DN MUST conform to RFC 2253.
Now this has a ripple effect on the OASIS profile. In particular, the metadata schema change proposed in section 3.8.1 can be removed because the need for it no longer exists (as stated, anyway). So altogether this is not a trivial modification of the profile.
agreed, because keyInfo has lots of optional elements and you will need to say which can be used and which cannot. Also, and more importantly, keyInfo says NOTHING about using proxy certificates or attribute certificates, and something like this is needed for delegation from the user to the SP. So it quite a bit of work to add this.
More importantly, it's not clear to me what normative language should be used when describing the SAML subject. I think a conforming IdP MUST support both X509SubjectName and the extension of saml2:BaseIDAbstractType, but the SP is free to use whatever it wants. I dare say this suggests that all of section 2 can be eliminated.
I agree.
So, no, this is not a cosmetic change. It will require a complete rewrite and we are back to square one. I guess I don't mind doing it, but I'll wait and see what others think.
Yes, but I suggest that the current spec might be broken anyway, in which case an update is needed anyway
regards
David
Tom
On Sat, Mar 22, 2008 at 12:49 PM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Hi Tom
thanks for taking the painful but necessary step of raising a defect.
Actually I dont think it is as bad as you say. The current draft is not erroneous, it is simply lacking in a non-essential though useful feature. The DN is not erroneous. It is perfectly OK and I would not suggest removing it. The reasons have already been given in my earlier discussions on Trust i.e. if the AA trusts the Grid SP then the DN of the Grid SP in the caller field (sorry may not have used the correct term here) and the DN of the user in the subject field (again may not be correct term) is sufficient to provide a perfectly good proxy service. It is also as scalable as Shibboleth is today (cf the metadata). So what you are proposing to add is a feature that will allow greater scalability and less configuring of trust meta data, since the user can dynamically delegate to a proxy to request attributes on his behalf. This is a nice additional feature to the current draft, but is not a show stopper in my opinion
Regards
David
Tom Scavo wrote:
On Sat, Mar 22, 2008 at 11:32 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
we do a dis-service to people by specifying a standard which we know to be deficient beforehand. This will cause even more delays in trying to rectify it (consider for example the OGSA Authz SAML spec, GFD 66, which was only found to be deficient after practical trials, and how long it has taken to produce replacements).
I suppose that is why the OASIS process requires three attestations (i.e., claims of successful implementation) before OASIS Standard status can be put to the vote.
My suggestion would be to raise a ballot comment now on the current OASIS draft, along with a proposed solution, so that this can be taken into account in the revision.
I tend to agree (reluctantly). What do others think?
Should the proposed solution require a <ds:KeyInfo> element and disallow an X509SubjectName identifier, or should it be more lax? That's really a tough call, I think.
If the process is anything like IETF or ISO it should not cause too much of a delay.
Such a change requires that we start from scratch, including another 60-day public review. The delay will be substantial.
Tom Scavo wrote:
On Sat, Mar 22, 2008 at 5:44 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote: > ...the inclusion of a "certificate" needs more elaboration. The > inclusion for example of a user's public key certificate proves nothing > more than the presence of a DN does, since it is publicly available and > an untrustworth grid SP could send any PKC it wished, just as it can > send any DN it wished. Therefore one needs to specify the properties of > the certificate that are being transferred, which is, that the user is > delegating to the grid SP to act on its behalf. A proxy certificate > would do this, as would an attribute certificate.
I totally agree. Of course this requires a new attribute request handler at the Shib AA but then a new handler is required for a bare DN as well, so there's no additional penalty. I don't know that much about the VOMS AA, but I'd be surprised if handling a full certificate turned out to be much of a problem for VOMS.
We have a dilemma, however. A formal ballot is currently underway to promote the OASIS SAML V2.0 Deployment Profiles for X.509 Subjects to Committee Specification status. I fully expect this ballot to succeed. The next step after Committee Specification is OASIS Standard (but this last step requires three attestations, which is unlikely).
If we introduce a normative change to the profile such as we've been discussing, we essentially start over. Presumably the profile could travel faster through committee this time around since the bulk of it has already been vetted, but a significant delay is inevitable.
The other alternative is to specify this new extension of saml2:BaseIDAbstractType in our Attribute Exchange profile and leave the OASIS profile alone, flawed as it is. A third alternative is to do nothing.
I'm not sure what to recommend. I'll let others comment on the appropriate course of action.
Tom
> Tom Scavo wrote: > > > > Instead of *requiring* a DN, the name identifier in the query should > > be generalized to accommodate the entire certificate (without > > excluding the possibility of a naked DN in those situations where it > > is warranted). This can be done using <ds:KeyInfo>, something like > > this: > > > > <saml:Subject> > > <saml:BaseID xsi:type="KeyIdentifierType"> > > <ds:KeyInfo>...</ds:KeyInfo> > > </saml:BaseID> > > </saml:Subject> > > > > where KeyIdentifierType is defined as follows: > > > > <complexType name="KeyIdentifierType"> > > <complexContent> > > <extension base="saml:BaseIDAbstractType"> > > <sequence> > > <element ref="ds:KeyInfo"/> > > </sequence> > > </extension> > > </complexContent> > > </complexType>
--
***************************************************************** 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
*****************************************************************
![](https://secure.gravatar.com/avatar/25170d7bd06dd4d753053e12888d1bb0.jpg?s=120&d=mm&r=g)
Hi, I'm sorry to jump into the exchange so late, but I wasn't able to do it before. I was reading the thread, and everything is pretty smooth until David's March 22th 10:44 mail. At that point, to my understanding, it's not cleat whether there's really a problem with the OASIS profile. What Tom has brought to our attention is that profile would lack the possibility for the IdP that receives a query to determine whether the requester is authorized to get the subjet's attributes. Intially, the problem was stated as proving user presence at the SP, but I think it's more generally an authz problem. User presence it's only a possible policy the IdP may have for authorizing requests. The IdP has to decide whether to allow the request, and each service will have policies for that. I wouldn't suggest doing as I did in the prototype, allowing after the SP's DN, but it's a way. Or, the IdP may issue an authorization decision query to a PDP. I don't see this as a protocol problem. It can become a protocol problem if the protocol doesn't allow to pass all the info needed to the IdP to drive his authorization decision. But I haven't understood why the cert would say much more than the dn for that. Before discussing how to handle a problem with the spec, can you help me understand that? Valerio On Sat, 2008-03-22 at 10:31 -0400, Tom Scavo wrote:
On Sat, Mar 22, 2008 at 5:44 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
...the inclusion of a "certificate" needs more elaboration. The inclusion for example of a user's public key certificate proves nothing more than the presence of a DN does, since it is publicly available and an untrustworth grid SP could send any PKC it wished, just as it can send any DN it wished. Therefore one needs to specify the properties of the certificate that are being transferred, which is, that the user is delegating to the grid SP to act on its behalf. A proxy certificate would do this, as would an attribute certificate.
I totally agree. Of course this requires a new attribute request handler at the Shib AA but then a new handler is required for a bare DN as well, so there's no additional penalty. I don't know that much about the VOMS AA, but I'd be surprised if handling a full certificate turned out to be much of a problem for VOMS.
We have a dilemma, however. A formal ballot is currently underway to promote the OASIS SAML V2.0 Deployment Profiles for X.509 Subjects to Committee Specification status. I fully expect this ballot to succeed. The next step after Committee Specification is OASIS Standard (but this last step requires three attestations, which is unlikely).
If we introduce a normative change to the profile such as we've been discussing, we essentially start over. Presumably the profile could travel faster through committee this time around since the bulk of it has already been vetted, but a significant delay is inevitable.
The other alternative is to specify this new extension of saml2:BaseIDAbstractType in our Attribute Exchange profile and leave the OASIS profile alone, flawed as it is. A third alternative is to do nothing.
I'm not sure what to recommend. I'll let others comment on the appropriate course of action.
Tom
Tom Scavo wrote:
Instead of *requiring* a DN, the name identifier in the query should be generalized to accommodate the entire certificate (without excluding the possibility of a naked DN in those situations where it is warranted). This can be done using <ds:KeyInfo>, something like this:
<saml:Subject> <saml:BaseID xsi:type="KeyIdentifierType"> <ds:KeyInfo>...</ds:KeyInfo> </saml:BaseID> </saml:Subject>
where KeyIdentifierType is defined as follows:
<complexType name="KeyIdentifierType"> <complexContent> <extension base="saml:BaseIDAbstractType"> <sequence> <element ref="ds:KeyInfo"/> </sequence> </extension> </complexContent> </complexType>
![](https://secure.gravatar.com/avatar/6e1526a3d8af0bb09676f1b771810cf4.jpg?s=120&d=mm&r=g)
Valerio Venturi wrote:
Hi, I'm sorry to jump into the exchange so late, but I wasn't able to do it before. I was reading the thread, and everything is pretty smooth until David's March 22th 10:44 mail. At that point, to my understanding, it's not cleat whether there's really a problem with the OASIS profile. What Tom has brought to our attention is that profile would lack the possibility for the IdP that receives a query to determine whether the requester is authorized to get the subjet's attributes. Intially, the problem was stated as proving user presence at the SP, but I think it's more generally an authz problem. User presence it's only a possible policy the IdP may have for authorizing requests. The IdP has to decide whether to allow the request, and each service will have policies for that. I wouldn't suggest doing as I did in the prototype, allowing after the SP's DN, but it's a way. Or, the IdP may issue an authorization decision query to a PDP.
And if you are not careful you end up with recursion, because the PDP needs to pull the user's attributes to see if he is authorised, and this causes the AA which is being pulled from to ask another PDP if the requester if authorised to pull the attributes ... ad infinitum. regards David
I don't see this as a protocol problem. It can become a protocol problem if the protocol doesn't allow to pass all the info needed to the IdP to drive his authorization decision. But I haven't understood why the cert would say much more than the dn for that. Before discussing how to handle a problem with the spec, can you help me understand that?
Valerio
On Sat, 2008-03-22 at 10:31 -0400, Tom Scavo wrote:
On Sat, Mar 22, 2008 at 5:44 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
...the inclusion of a "certificate" needs more elaboration. The inclusion for example of a user's public key certificate proves nothing more than the presence of a DN does, since it is publicly available and an untrustworth grid SP could send any PKC it wished, just as it can send any DN it wished. Therefore one needs to specify the properties of the certificate that are being transferred, which is, that the user is delegating to the grid SP to act on its behalf. A proxy certificate would do this, as would an attribute certificate. I totally agree. Of course this requires a new attribute request handler at the Shib AA but then a new handler is required for a bare DN as well, so there's no additional penalty. I don't know that much about the VOMS AA, but I'd be surprised if handling a full certificate turned out to be much of a problem for VOMS.
We have a dilemma, however. A formal ballot is currently underway to promote the OASIS SAML V2.0 Deployment Profiles for X.509 Subjects to Committee Specification status. I fully expect this ballot to succeed. The next step after Committee Specification is OASIS Standard (but this last step requires three attestations, which is unlikely).
If we introduce a normative change to the profile such as we've been discussing, we essentially start over. Presumably the profile could travel faster through committee this time around since the bulk of it has already been vetted, but a significant delay is inevitable.
The other alternative is to specify this new extension of saml2:BaseIDAbstractType in our Attribute Exchange profile and leave the OASIS profile alone, flawed as it is. A third alternative is to do nothing.
I'm not sure what to recommend. I'll let others comment on the appropriate course of action.
Tom
Tom Scavo wrote:
Instead of *requiring* a DN, the name identifier in the query should be generalized to accommodate the entire certificate (without excluding the possibility of a naked DN in those situations where it is warranted). This can be done using <ds:KeyInfo>, something like this:
<saml:Subject> <saml:BaseID xsi:type="KeyIdentifierType"> <ds:KeyInfo>...</ds:KeyInfo> </saml:BaseID> </saml:Subject>
where KeyIdentifierType is defined as follows:
<complexType name="KeyIdentifierType"> <complexContent> <extension base="saml:BaseIDAbstractType"> <sequence> <element ref="ds:KeyInfo"/> </sequence> </extension> </complexContent> </complexType>
-- ***************************************************************** 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 *****************************************************************
![](https://secure.gravatar.com/avatar/390e531f4f93461168de3b073b7cad07.jpg?s=120&d=mm&r=g)
David described a simple use case involving a proxy certificate: On Sat, Mar 22, 2008 at 5:44 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Secondly the inclusion of a "certificate" needs more elaboration. The inclusion for example of a user's public key certificate proves nothing more than the presence of a DN does, since it is publicly available and an untrustworth grid SP could send any PKC it wished, just as it can send any DN it wished. Therefore one needs to specify the properties of the certificate that are being transferred, which is, that the user is delegating to the grid SP to act on its behalf. A proxy certificate would do this, as would an attribute certificate.
Here's another possible use case involving an end entity certificate (EEC). Suppose a user requests a short-lived EEC from a shib-enabled online CA (such as the GridShib CA). The user first obtains a SAML assertion from the IdP and then presents this SAML assertion to the shib-enabled CA. The CA binds the SAML assertion (or portions of it) to the issued EEC. Now the user authenticates to a Grid SP using this EEC and thereafter the SP includes the EEC in its query to the IdP. The IdP recovers the SAML assertion in the EEC and verifies that it did in fact issue the assertion to the shib-enabled CA through the browser. This proves (to the satisfaction of the IdP) that the user is present at the Grid SP. Another use case involves a shib-enabled grid portal (such as a TeraGrid Science Gateway) that makes a request to a Grid SP on the user's behalf. In that case, the portal issues a proxy certificate containing the SAML assertion from the IdP, which it presents to the Grid SP. The Grid SP recovers the SAML assertion from the proxy and uses the SAML Subject therein to issue a query to the IdP. So neither a DN nor a certificate is required in this case. In the previous use case, if the IdP does not know the portal and the Grid SP are affiliated, it may reject the Grid SP's use of the SAML Subject. Thus the Grid SP might include the entire certificate in its query, which proves 1) the subject presented the SAML assertion to the grid portal, and 2) the grid portal requested the Grid SP on behalf of the user. The IdP may allow such a request, subject to policy. Tom On Tue, Apr 1, 2008 at 9:41 AM, Valerio Venturi <valerio.venturi@cnaf.infn.it> wrote:
Hi, I'm sorry to jump into the exchange so late, but I wasn't able to do it before. I was reading the thread, and everything is pretty smooth until David's March 22th 10:44 mail. At that point, to my understanding, it's not cleat whether there's really a problem with the OASIS profile. What Tom has brought to our attention is that profile would lack the possibility for the IdP that receives a query to determine whether the requester is authorized to get the subjet's attributes. Intially, the problem was stated as proving user presence at the SP, but I think it's more generally an authz problem. User presence it's only a possible policy the IdP may have for authorizing requests. The IdP has to decide whether to allow the request, and each service will have policies for that. I wouldn't suggest doing as I did in the prototype, allowing after the SP's DN, but it's a way. Or, the IdP may issue an authorization decision query to a PDP. I don't see this as a protocol problem. It can become a protocol problem if the protocol doesn't allow to pass all the info needed to the IdP to drive his authorization decision. But I haven't understood why the cert would say much more than the dn for that. Before discussing how to handle a problem with the spec, can you help me understand that?
Valerio
On Sat, 2008-03-22 at 10:31 -0400, Tom Scavo wrote:
On Sat, Mar 22, 2008 at 5:44 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
...the inclusion of a "certificate" needs more elaboration. The inclusion for example of a user's public key certificate proves nothing more than the presence of a DN does, since it is publicly available and an untrustworth grid SP could send any PKC it wished, just as it can send any DN it wished. Therefore one needs to specify the properties of the certificate that are being transferred, which is, that the user is delegating to the grid SP to act on its behalf. A proxy certificate would do this, as would an attribute certificate.
I totally agree. Of course this requires a new attribute request handler at the Shib AA but then a new handler is required for a bare DN as well, so there's no additional penalty. I don't know that much about the VOMS AA, but I'd be surprised if handling a full certificate turned out to be much of a problem for VOMS.
We have a dilemma, however. A formal ballot is currently underway to promote the OASIS SAML V2.0 Deployment Profiles for X.509 Subjects to Committee Specification status. I fully expect this ballot to succeed. The next step after Committee Specification is OASIS Standard (but this last step requires three attestations, which is unlikely).
If we introduce a normative change to the profile such as we've been discussing, we essentially start over. Presumably the profile could travel faster through committee this time around since the bulk of it has already been vetted, but a significant delay is inevitable.
The other alternative is to specify this new extension of saml2:BaseIDAbstractType in our Attribute Exchange profile and leave the OASIS profile alone, flawed as it is. A third alternative is to do nothing.
I'm not sure what to recommend. I'll let others comment on the appropriate course of action.
Tom
Tom Scavo wrote:
Instead of *requiring* a DN, the name identifier in the query should be generalized to accommodate the entire certificate (without excluding the possibility of a naked DN in those situations where it is warranted). This can be done using <ds:KeyInfo>, something like this:
<saml:Subject> <saml:BaseID xsi:type="KeyIdentifierType"> <ds:KeyInfo>...</ds:KeyInfo> </saml:BaseID> </saml:Subject>
where KeyIdentifierType is defined as follows:
<complexType name="KeyIdentifierType"> <complexContent> <extension base="saml:BaseIDAbstractType"> <sequence> <element ref="ds:KeyInfo"/> </sequence> </extension> </complexContent> </complexType>
![](https://secure.gravatar.com/avatar/25170d7bd06dd4d753053e12888d1bb0.jpg?s=120&d=mm&r=g)
Hi, On Tue, 2008-04-01 at 11:44 -0400, Tom Scavo wrote:
David described a simple use case involving a proxy certificate:
On Sat, Mar 22, 2008 at 5:44 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Secondly the inclusion of a "certificate" needs more elaboration. The inclusion for example of a user's public key certificate proves nothing more than the presence of a DN does, since it is publicly available and an untrustworth grid SP could send any PKC it wished, just as it can send any DN it wished. Therefore one needs to specify the properties of the certificate that are being transferred, which is, that the user is delegating to the grid SP to act on its behalf. A proxy certificate would do this, as would an attribute certificate.
A proxy proves delegation if it's used by the SP to authenticate to the IdP, not if it's passed in the the query, unless you're suggesting to pass the private key.
Here's another possible use case involving an end entity certificate (EEC). Suppose a user requests a short-lived EEC from a shib-enabled online CA (such as the GridShib CA). The user first obtains a SAML assertion from the IdP and then presents this SAML assertion to the shib-enabled CA. The CA binds the SAML assertion (or portions of it) to the issued EEC.
Now the user authenticates to a Grid SP using this EEC and thereafter the SP includes the EEC in its query to the IdP. The IdP recovers the SAML assertion in the EEC and verifies that it did in fact issue the assertion to the shib-enabled CA through the browser. This proves (to the satisfaction of the IdP) that the user is present at the Grid SP.
I don't get what assures that the step 'the user authenticates to a Grid SP using this EEC' has been going through. The EEC is public stuff, and the SP could well have get it by another mean. The user, after having had the EEC by the shib-enabled CA, may make it available on the web.Why shouldn't he? It should be safe. A SP can get it and go to the IdP. What would be different than if the user had authenticated?
Another use case involves a shib-enabled grid portal (such as a TeraGrid Science Gateway) that makes a request to a Grid SP on the user's behalf. In that case, the portal issues a proxy certificate containing the SAML assertion from the IdP, which it presents to the Grid SP. The Grid SP recovers the SAML assertion from the proxy and uses the SAML Subject therein to issue a query to the IdP. So neither a DN nor a certificate is required in this case.
In the previous use case, if the IdP does not know the portal and the Grid SP are affiliated, it may reject the Grid SP's use of the SAML Subject. Thus the Grid SP might include the entire certificate in its query, which proves 1) the subject presented the SAML assertion to the grid portal, and 2) the grid portal requested the Grid SP on behalf of the user. The IdP may allow such a request, subject to policy.
See remark above, I don't think the certificate being in the query proves 1. For what concern 2, does the IdP care? Anyway, don't you think that this would be abusing of the Subject element? The Subject element 'specifies the principal that is the subject of all of the statements in the assertions'. It's not supposed to carry EEC or SAML assertions or proxy, as in the first use case. Unless that is for the purpose of identifying the subject. And for identifying the subject, the DN is well enough. If a IdP requires by authz policy that the EEC of the subject is passed, I don't think we should force the query to allow that. The consumer may use other means of passing such information, for example WS-Security when the services are SOAP enabled. Valerio
![](https://secure.gravatar.com/avatar/390e531f4f93461168de3b073b7cad07.jpg?s=120&d=mm&r=g)
Sorry for not getting back to you sooner. I got caught up in a software release activity here at NCSA. See inline responses below. On Tue, Apr 1, 2008 at 12:53 PM, Valerio Venturi <valerio.venturi@cnaf.infn.it> wrote:
On Tue, 2008-04-01 at 11:44 -0400, Tom Scavo wrote:
David described a simple use case involving a proxy certificate:
On Sat, Mar 22, 2008 at 5:44 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Secondly the inclusion of a "certificate" needs more elaboration. The inclusion for example of a user's public key certificate proves nothing more than the presence of a DN does, since it is publicly available and an untrustworth grid SP could send any PKC it wished, just as it can send any DN it wished. Therefore one needs to specify the properties of the certificate that are being transferred, which is, that the user is delegating to the grid SP to act on its behalf. A proxy certificate would do this, as would an attribute certificate.
A proxy proves delegation if it's used by the SP to authenticate to the IdP, not if it's passed in the the query, unless you're suggesting to pass the private key.
Sorry, I've been using the word "prove" inappropriately perhaps. The Grid SP doesn't "prove" user presence in the same way a presenter proves possession of a private key. The Grid SP does provide evidence of user presence, however, some evidence being more convincing than others, of course. Remember, I'm not talking about self-query here, I'm talking about standalone attribute query (also called "cold query"). If I were managing the IdP at the University of Illinois, I would not accept standalone attribute queries from SPs, even if I trusted the SP in other respects. So it doesn't matter if the SP is in metadata or on an ACL; as an IdP I need proof (or evidence) of user presence. For example, the UI IdP trusts all InCommon SPs, so does that mean the UI IdP will respond to cold queries from any InCommon SP? Any of those SPs can put my DN into a query (at any time) and submit it to the UI IdP, so how does the IdP know that I (the user) am actually involved in the transaction? Something has to be done to limit the SP's ability to query for my attributes.
Here's another possible use case involving an end entity certificate (EEC). Suppose a user requests a short-lived EEC from a shib-enabled online CA (such as the GridShib CA). The user first obtains a SAML assertion from the IdP and then presents this SAML assertion to the shib-enabled CA. The CA binds the SAML assertion (or portions of it) to the issued EEC.
Now the user authenticates to a Grid SP using this EEC and thereafter the SP includes the EEC in its query to the IdP. The IdP recovers the SAML assertion in the EEC and verifies that it did in fact issue the assertion to the shib-enabled CA through the browser. This proves (to the satisfaction of the IdP) that the user is present at the Grid SP.
I don't get what assures that the step 'the user authenticates to a Grid SP using this EEC' has been going through. The EEC is public stuff, and the SP could well have get it by another mean. The user, after having had the EEC by the shib-enabled CA, may make it available on the web.Why shouldn't he? It should be safe. A SP can get it and go to the IdP. What would be different than if the user had authenticated?
Well, the first thing to note is that the EEC is short-lived (like a typical proxy), so it's not going to be around long enough to be abused. Second thing to note is that a SAML assertion is cryptographically bound to the EEC by the CA, and likewise there is a token bound to the SAML assertion. The IdP bound that token when I authenticated, and only the IdP can unravel that token. An example of such a token is the well-known CryptoShibHandle.
Another use case involves a shib-enabled grid portal (such as a TeraGrid Science Gateway) that makes a request to a Grid SP on the user's behalf. In that case, the portal issues a proxy certificate containing the SAML assertion from the IdP, which it presents to the Grid SP. The Grid SP recovers the SAML assertion from the proxy and uses the SAML Subject therein to issue a query to the IdP. So neither a DN nor a certificate is required in this case.
In the previous use case, if the IdP does not know the portal and the Grid SP are affiliated, it may reject the Grid SP's use of the SAML Subject. Thus the Grid SP might include the entire certificate in its query, which proves 1) the subject presented the SAML assertion to the grid portal, and 2) the grid portal requested the Grid SP on behalf of the user. The IdP may allow such a request, subject to policy.
See remark above, I don't think the certificate being in the query proves 1.
Why not? The SAML assertion has a 10-minute lifetime. If the grid portal does as I suggest above, in the time allotted, has the portal not provided sufficient evidence that I (the user) very recently visited the portal?
For what concern 2, does the IdP care?
As I said above, in the case of standalone attribute query (cold query), in general the IdP very much cares that the user and the portal are legitimately involved in the transaction. This effectively limits the Grid SP's ability to query for my attributes.
Anyway, don't you think that this would be abusing of the Subject element?
Not at all.
The Subject element 'specifies the principal that is the subject of all of the statements in the assertions'.
The SP is the producer of the Subject element, not the IdP. In a query, it is the SP that produces the SAML Subject element. The IdP just follows suit (see the notion of "strongly matches" in [SAMLCore]).
It's not supposed to carry EEC or SAML assertions or proxy, as in the first use case. Unless that is for the purpose of identifying the subject. And for identifying the subject, the DN is well enough.
If the IdP trusts the Grid SP to request attributes only when there's a legitimate user request in progress in the background, then yes, a DN will suffice. In general, that trust may not exist, so we need a mechanism that an SP can use to "prove" (maybe that's too strong of a word) user presence.
If a IdP requires by authz policy that the EEC of the subject is passed, I don't think we should force the query to allow that.
No, I never said the SP MUST use a certificate, but I don't think the SP MUST use a DN either. (I've just outlined a use case where neither is required in fact.) In the case of query (not self-query), here's the suggested normative language: - An SP MAY use an X509SubjectName name identifier or an identifier of type KeyIdentifierType. [The latter was defined previously, as a suitably constrained <ds:KeyInfo> element.] - An IdP MUST support X509SubjectName. Other NameID formats, including KeyIdentifierType, MAY be supported by the IdP.
The consumer may use other means of passing such information, for example WS-Security when the services are SOAP enabled.
I know of no WSS profile that covers this use case where the requester is acting on behalf of the subject. That said, that's an interesting idea, putting an X.509 token in the SOAP header, and a SAML request in the SOAP body. That requires quite a bit more than an ordinary SAML SOAP responder, however. It would be much harder to implement. Tom
![](https://secure.gravatar.com/avatar/6e1526a3d8af0bb09676f1b771810cf4.jpg?s=120&d=mm&r=g)
Hi Tom my feeling is that constructing a protocol from the end user via the GridSP to the IDP to prove user presence when the GridSP asks the IDP for user attributes, is a long term project and will require a new work item for it. I dont see any simple protocol solutions at the moment. However, there is a simple solution available now by requiring the IDP and GridSP to have a trust relationship which requires the GridSP to only issues queries when a user is present. This trust relationship can be cemented by the IDP configuring the names of the trusted GridSPs into its SAML service. This is the approach that Valerio has adopted today. This approach can also be scaled up to federation level by requiring federation members to honour this requirement, and then the IDP only needs to configure in the root of trust of the federation, and any federation member issued with a credential by the federation root becomes trusted to make queries from the federation IDPs. However, when you want to replace out of band trust with in band protocol to prove user presence, this becomes much more complex and I think we simply have to punt this for now regards David Tom Scavo wrote:
Sorry for not getting back to you sooner. I got caught up in a software release activity here at NCSA. See inline responses below.
On Tue, Apr 1, 2008 at 12:53 PM, Valerio Venturi <valerio.venturi@cnaf.infn.it> wrote:
On Tue, 2008-04-01 at 11:44 -0400, Tom Scavo wrote:
David described a simple use case involving a proxy certificate:
On Sat, Mar 22, 2008 at 5:44 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Secondly the inclusion of a "certificate" needs more elaboration. The inclusion for example of a user's public key certificate proves nothing more than the presence of a DN does, since it is publicly available and an untrustworth grid SP could send any PKC it wished, just as it can send any DN it wished. Therefore one needs to specify the properties of the certificate that are being transferred, which is, that the user is delegating to the grid SP to act on its behalf. A proxy certificate would do this, as would an attribute certificate.
A proxy proves delegation if it's used by the SP to authenticate to the IdP, not if it's passed in the the query, unless you're suggesting to pass the private key.
Sorry, I've been using the word "prove" inappropriately perhaps. The Grid SP doesn't "prove" user presence in the same way a presenter proves possession of a private key. The Grid SP does provide evidence of user presence, however, some evidence being more convincing than others, of course.
Remember, I'm not talking about self-query here, I'm talking about standalone attribute query (also called "cold query"). If I were managing the IdP at the University of Illinois, I would not accept standalone attribute queries from SPs, even if I trusted the SP in other respects. So it doesn't matter if the SP is in metadata or on an ACL; as an IdP I need proof (or evidence) of user presence.
For example, the UI IdP trusts all InCommon SPs, so does that mean the UI IdP will respond to cold queries from any InCommon SP? Any of those SPs can put my DN into a query (at any time) and submit it to the UI IdP, so how does the IdP know that I (the user) am actually involved in the transaction? Something has to be done to limit the SP's ability to query for my attributes.
Here's another possible use case involving an end entity certificate (EEC). Suppose a user requests a short-lived EEC from a shib-enabled online CA (such as the GridShib CA). The user first obtains a SAML assertion from the IdP and then presents this SAML assertion to the shib-enabled CA. The CA binds the SAML assertion (or portions of it) to the issued EEC.
Now the user authenticates to a Grid SP using this EEC and thereafter the SP includes the EEC in its query to the IdP. The IdP recovers the SAML assertion in the EEC and verifies that it did in fact issue the assertion to the shib-enabled CA through the browser. This proves (to the satisfaction of the IdP) that the user is present at the Grid SP.
I don't get what assures that the step 'the user authenticates to a Grid SP using this EEC' has been going through. The EEC is public stuff, and the SP could well have get it by another mean. The user, after having had the EEC by the shib-enabled CA, may make it available on the web.Why shouldn't he? It should be safe. A SP can get it and go to the IdP. What would be different than if the user had authenticated?
Well, the first thing to note is that the EEC is short-lived (like a typical proxy), so it's not going to be around long enough to be abused. Second thing to note is that a SAML assertion is cryptographically bound to the EEC by the CA, and likewise there is a token bound to the SAML assertion. The IdP bound that token when I authenticated, and only the IdP can unravel that token. An example of such a token is the well-known CryptoShibHandle.
Another use case involves a shib-enabled grid portal (such as a TeraGrid Science Gateway) that makes a request to a Grid SP on the user's behalf. In that case, the portal issues a proxy certificate containing the SAML assertion from the IdP, which it presents to the Grid SP. The Grid SP recovers the SAML assertion from the proxy and uses the SAML Subject therein to issue a query to the IdP. So neither a DN nor a certificate is required in this case.
In the previous use case, if the IdP does not know the portal and the Grid SP are affiliated, it may reject the Grid SP's use of the SAML Subject. Thus the Grid SP might include the entire certificate in its query, which proves 1) the subject presented the SAML assertion to the grid portal, and 2) the grid portal requested the Grid SP on behalf of the user. The IdP may allow such a request, subject to policy.
See remark above, I don't think the certificate being in the query proves 1.
Why not? The SAML assertion has a 10-minute lifetime. If the grid portal does as I suggest above, in the time allotted, has the portal not provided sufficient evidence that I (the user) very recently visited the portal?
For what concern 2, does the IdP care?
As I said above, in the case of standalone attribute query (cold query), in general the IdP very much cares that the user and the portal are legitimately involved in the transaction. This effectively limits the Grid SP's ability to query for my attributes.
Anyway, don't you think that this would be abusing of the Subject element?
Not at all.
The Subject element 'specifies the principal that is the subject of all of the statements in the assertions'.
The SP is the producer of the Subject element, not the IdP. In a query, it is the SP that produces the SAML Subject element. The IdP just follows suit (see the notion of "strongly matches" in [SAMLCore]).
It's not supposed to carry EEC or SAML assertions or proxy, as in the first use case. Unless that is for the purpose of identifying the subject. And for identifying the subject, the DN is well enough.
If the IdP trusts the Grid SP to request attributes only when there's a legitimate user request in progress in the background, then yes, a DN will suffice. In general, that trust may not exist, so we need a mechanism that an SP can use to "prove" (maybe that's too strong of a word) user presence.
If a IdP requires by authz policy that the EEC of the subject is passed, I don't think we should force the query to allow that.
No, I never said the SP MUST use a certificate, but I don't think the SP MUST use a DN either. (I've just outlined a use case where neither is required in fact.) In the case of query (not self-query), here's the suggested normative language:
- An SP MAY use an X509SubjectName name identifier or an identifier of type KeyIdentifierType. [The latter was defined previously, as a suitably constrained <ds:KeyInfo> element.]
- An IdP MUST support X509SubjectName. Other NameID formats, including KeyIdentifierType, MAY be supported by the IdP.
The consumer may use other means of passing such information, for example WS-Security when the services are SOAP enabled.
I know of no WSS profile that covers this use case where the requester is acting on behalf of the subject. That said, that's an interesting idea, putting an X.509 token in the SOAP header, and a SAML request in the SOAP body. That requires quite a bit more than an ordinary SAML SOAP responder, however. It would be much harder to implement.
Tom
-- ***************************************************************** 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 *****************************************************************
![](https://secure.gravatar.com/avatar/390e531f4f93461168de3b073b7cad07.jpg?s=120&d=mm&r=g)
Okay, if the WG deems this issue to be out of scope, I'm okay with that. In that case, I won't touch the OASIS profile as it stands right now. If I do decide to address this issue at some point, it will be in a separate document. Thanks, David. Tom On Sat, Apr 5, 2008 at 1:24 PM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Hi Tom
my feeling is that constructing a protocol from the end user via the GridSP to the IDP to prove user presence when the GridSP asks the IDP for user attributes, is a long term project and will require a new work item for it. I dont see any simple protocol solutions at the moment.
However, there is a simple solution available now by requiring the IDP and GridSP to have a trust relationship which requires the GridSP to only issues queries when a user is present. This trust relationship can be cemented by the IDP configuring the names of the trusted GridSPs into its SAML service. This is the approach that Valerio has adopted today.
This approach can also be scaled up to federation level by requiring federation members to honour this requirement, and then the IDP only needs to configure in the root of trust of the federation, and any federation member issued with a credential by the federation root becomes trusted to make queries from the federation IDPs.
However, when you want to replace out of band trust with in band protocol to prove user presence, this becomes much more complex and I think we simply have to punt this for now
regards
David
Tom Scavo wrote:
Sorry for not getting back to you sooner. I got caught up in a software release activity here at NCSA. See inline responses below.
On Tue, Apr 1, 2008 at 12:53 PM, Valerio Venturi <valerio.venturi@cnaf.infn.it> wrote:
David described a simple use case involving a proxy certificate:
On Sat, Mar 22, 2008 at 5:44 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Secondly the inclusion of a "certificate" needs more elaboration.
The
inclusion for example of a user's public key certificate proves nothing more than the presence of a DN does, since it is publicly available and an untrustworth grid SP could send any PKC it wished, just as it can send any DN it wished. Therefore one needs to specify the
On Tue, 2008-04-01 at 11:44 -0400, Tom Scavo wrote: properties of
the certificate that are being transferred, which is, that the user is delegating to the grid SP to act on its behalf. A proxy certificate would do this, as would an attribute certificate.
A proxy proves delegation if it's used by the SP to authenticate to the IdP, not if it's passed in the the query, unless you're suggesting to pass the private key.
Sorry, I've been using the word "prove" inappropriately perhaps. The Grid SP doesn't "prove" user presence in the same way a presenter proves possession of a private key. The Grid SP does provide evidence of user presence, however, some evidence being more convincing than others, of course.
Remember, I'm not talking about self-query here, I'm talking about standalone attribute query (also called "cold query"). If I were managing the IdP at the University of Illinois, I would not accept standalone attribute queries from SPs, even if I trusted the SP in other respects. So it doesn't matter if the SP is in metadata or on an ACL; as an IdP I need proof (or evidence) of user presence.
For example, the UI IdP trusts all InCommon SPs, so does that mean the UI IdP will respond to cold queries from any InCommon SP? Any of those SPs can put my DN into a query (at any time) and submit it to the UI IdP, so how does the IdP know that I (the user) am actually involved in the transaction? Something has to be done to limit the SP's ability to query for my attributes.
Here's another possible use case involving an end entity certificate (EEC). Suppose a user requests a short-lived EEC from a shib-enabled online CA (such as the GridShib CA). The user first obtains a SAML assertion from the IdP and then presents this SAML assertion to the shib-enabled CA. The CA binds the SAML assertion (or portions of it) to the issued EEC.
Now the user authenticates to a Grid SP using this EEC and thereafter the SP includes the EEC in its query to the IdP. The IdP recovers the SAML assertion in the EEC and verifies that it did in fact issue the assertion to the shib-enabled CA through the browser. This proves (to the satisfaction of the IdP) that the user is present at the Grid SP.
I don't get what assures that the step 'the user authenticates to a Grid SP using this EEC' has been going through. The EEC is public stuff, and the SP could well have get it by another mean. The user, after having had the EEC by the shib-enabled CA, may make it available on the web.Why shouldn't he? It should be safe. A SP can get it and go to the IdP. What would be different than if the user had authenticated?
Well, the first thing to note is that the EEC is short-lived (like a typical proxy), so it's not going to be around long enough to be abused. Second thing to note is that a SAML assertion is cryptographically bound to the EEC by the CA, and likewise there is a token bound to the SAML assertion. The IdP bound that token when I authenticated, and only the IdP can unravel that token. An example of such a token is the well-known CryptoShibHandle.
Another use case involves a shib-enabled grid portal (such as a TeraGrid Science Gateway) that makes a request to a Grid SP on the user's behalf. In that case, the portal issues a proxy certificate containing the SAML assertion from the IdP, which it presents to the Grid SP. The Grid SP recovers the SAML assertion from the proxy and uses the SAML Subject therein to issue a query to the IdP. So neither a DN nor a certificate is required in this case.
In the previous use case, if the IdP does not know the portal and the Grid SP are affiliated, it may reject the Grid SP's use of the SAML Subject. Thus the Grid SP might include the entire certificate in its query, which proves 1) the subject presented the SAML assertion to the grid portal, and 2) the grid portal requested the Grid SP on behalf of the user. The IdP may allow such a request, subject to policy.
See remark above, I don't think the certificate being in the query proves 1.
Why not? The SAML assertion has a 10-minute lifetime. If the grid portal does as I suggest above, in the time allotted, has the portal not provided sufficient evidence that I (the user) very recently visited the portal?
For what concern 2, does the IdP care?
As I said above, in the case of standalone attribute query (cold query), in general the IdP very much cares that the user and the portal are legitimately involved in the transaction. This effectively limits the Grid SP's ability to query for my attributes.
Anyway, don't you think that this would be abusing of the Subject element?
Not at all.
The Subject element 'specifies the principal that is the subject of all of the statements in the assertions'.
The SP is the producer of the Subject element, not the IdP. In a query, it is the SP that produces the SAML Subject element. The IdP just follows suit (see the notion of "strongly matches" in [SAMLCore]).
It's not supposed to carry EEC or SAML assertions or proxy, as in the first use case. Unless that is for the purpose of identifying the subject. And for identifying the subject, the DN is well enough.
If the IdP trusts the Grid SP to request attributes only when there's a legitimate user request in progress in the background, then yes, a DN will suffice. In general, that trust may not exist, so we need a mechanism that an SP can use to "prove" (maybe that's too strong of a word) user presence.
If a IdP requires by authz policy that the EEC of the subject is passed, I don't think we should force the query to allow that.
No, I never said the SP MUST use a certificate, but I don't think the SP MUST use a DN either. (I've just outlined a use case where neither is required in fact.) In the case of query (not self-query), here's the suggested normative language:
- An SP MAY use an X509SubjectName name identifier or an identifier of type KeyIdentifierType. [The latter was defined previously, as a suitably constrained <ds:KeyInfo> element.]
- An IdP MUST support X509SubjectName. Other NameID formats, including KeyIdentifierType, MAY be supported by the IdP.
The consumer may use other means of passing such information, for example WS-Security when the services are SOAP enabled.
I know of no WSS profile that covers this use case where the requester is acting on behalf of the subject. That said, that's an interesting idea, putting an X.509 token in the SOAP header, and a SAML request in the SOAP body. That requires quite a bit more than an ordinary SAML SOAP responder, however. It would be much harder to implement.
Tom
--
***************************************************************** 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
*****************************************************************
![](https://secure.gravatar.com/avatar/08153869298cee788c06078284171032.jpg?s=120&d=mm&r=g)
On Mar 22, 2008, at 4:44 AM, David Chadwick wrote:
if you have followed a lot of the (old) discussions on the PKIX list about DN matching in certificates, you will see that a lot of PKI software vendors do plain string matching of DNs, rather than proper X.500/LDAP DN matching rules, so dont believe that passing certs instead of DNs will solve this problem. It wont. Only proper DN matching software will solve this, so it is irrelevant whether the DN is passed as a string or in a cert.
David et al., With respect to the point above, thought you might be interested in the following link. Topic: PathFinder is designed to provide a mechanism for any program to perform RFC3280-compliant path validation of X509 certificates, even when some of the intermediate certificates are not present on the local machine. By design, Pathfinder automatically downloads any such certificates (and their CRLs) from the Internet as needed using the AIA and CRL distribution point extensions of the certificates it is processing. Link: http://code.google.com/p/pathfinder-pki/ Alan Alan Sill, Ph.D TIGRE Senior Scientist, High Performance Computing Center Adjunct Professor of Physics TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
![](https://secure.gravatar.com/avatar/6e1526a3d8af0bb09676f1b771810cf4.jpg?s=120&d=mm&r=g)
Hi All, Here are Kent's implementation details Profile being implemented: OGSA Attribute Exchange Profile Organisation doing the implementation: University of Kent Contact details: d.w.chadwick@kent.ac.uk Short description: PERMIS will be the client and VOMS will be the server. This will implement the attribute pull model. INFN will provide the server implementation. Part of the UK VPMan project. Profile being implemented: XACML Request Context to Obtain an Authorization Decision Organisation doing the implementation: University of Kent Contact details: d.w.chadwick@kent.ac.uk Short description: We have implemented both the client and server ends, with GT4 being the client and the PERMIS PDP being the server. Profile being implemented: WS-Trust to a CVS Organisation doing the implementation: University of Kent Contact details: d.w.chadwick@kent.ac.uk Short description: we have implemented both the client and server components, with GT4 being the client and PERMIS CVS being the server. Regards, David On Sat, 2007-11-17 at 11:56 +0000, David Chadwick wrote:
Dear WG
I would like to draw up a table of implementations of the 3 protocol profile docs that we have published (XACML, WS-Trust and SAML AA).
The information that would be useful for the group is
Profile being implemented: Organisation doing the implementation: Contact details: Short description:
(the latter to contain such things as status of implementation, any interworking carried out, where software might be obtained etc. Whatever you feel is appropriate for the WG)
regards
David
![](https://secure.gravatar.com/avatar/390e531f4f93461168de3b073b7cad07.jpg?s=120&d=mm&r=g)
Hi David, On 11/20/07, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Profile being implemented: OGSA Attribute Exchange Profile Organisation doing the implementation: University of Kent Contact details: d.w.chadwick@kent.ac.uk Short description: PERMIS will be the client and VOMS will be the server. This will implement the attribute pull model. INFN will provide the server implementation. Part of the UK VPMan project.
Are you implementing the SAML Attribute Query Deployment Profile for X.509 Subjects or SAML Attribute Self-Query Deployment Profile for X.509 Subjects (or both)? Tom
![](https://secure.gravatar.com/avatar/6e1526a3d8af0bb09676f1b771810cf4.jpg?s=120&d=mm&r=g)
Hi Tom its the former we want for our GT4/VOMS/PERMIS implementation so that the PEP can have its own private key and does not need to keep getting the private key of the user (which the self-query profile requires). I talked to Valerio about this at OGF21, since his first implementation only supported the self-query profile. My understanding is that Valerio is enhancing his server implementation to support the former profile as well regards David Tom Scavo wrote:
Hi David,
On 11/20/07, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Profile being implemented: OGSA Attribute Exchange Profile Organisation doing the implementation: University of Kent Contact details: d.w.chadwick@kent.ac.uk Short description: PERMIS will be the client and VOMS will be the server. This will implement the attribute pull model. INFN will provide the server implementation. Part of the UK VPMan project.
Are you implementing the SAML Attribute Query Deployment Profile for X.509 Subjects or SAML Attribute Self-Query Deployment Profile for X.509 Subjects (or both)?
Tom
-- ***************************************************************** 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 *****************************************************************
![](https://secure.gravatar.com/avatar/21ca953f8bec0d83aa00e1f77195a403.jpg?s=120&d=mm&r=g)
Hi David, On Nov 17, 2007 12:56 PM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Dear WG
I would like to draw up a table of implementations of the 3 protocol profile docs
Those three protocol docs you mentioned are? : Use of XACML Request Context to Obtain an Authorisation Decision<https://forge.gridforum.org/sf/go/doc14565?nav=1> Use of WS-TRUST and SAML to access a CVS v0.3<https://forge.gridforum.org/sf/go/doc14908?nav=1> Use of SAML for OGSA Authorization<https://forge.gridforum.org/sf/go/doc8997?nav=1> Thanks Weizhong
that we have published (XACML, WS-Trust and SAML AA).
The information that would be useful for the group is
Profile being implemented: Organisation doing the implementation: Contact details: Short description:
(the latter to contain such things as status of implementation, any interworking carried out, where software might be obtained etc. Whatever you feel is appropriate for the WG)
regards
David
--
***************************************************************** 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
***************************************************************** -- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
![](https://secure.gravatar.com/avatar/6e1526a3d8af0bb09676f1b771810cf4.jpg?s=120&d=mm&r=g)
wz qiang wrote:
Hi David,
On Nov 17, 2007 12:56 PM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Dear WG
I would like to draw up a table of implementations of the 3 protocol profile docs
Those three protocol docs you mentioned are? : Use of XACML Request Context to Obtain an Authorisation Decision<https://forge.gridforum.org/sf/go/doc14565?nav=1>
Yes, dated 31 Oct 2007
Use of WS-TRUST and SAML to access a CVS v0.3<https://forge.gridforum.org/sf/go/doc14908?nav=1>
Yes, dated 31 Oct 2007
Use of SAML for OGSA Authorization<https://forge.gridforum.org/sf/go/doc8997?nav=1>
No. The doc you need is OGSA Attribute Exchange Profile Version 1.0 dated 29 oct 2007. Available from https://forge.gridforum.org/sf/go/doc14905?nav=1 regards David
Thanks Weizhong
that we have published (XACML, WS-Trust and SAML AA).
The information that would be useful for the group is
Profile being implemented: Organisation doing the implementation: Contact details: Short description:
(the latter to contain such things as status of implementation, any interworking carried out, where software might be obtained etc. Whatever you feel is appropriate for the WG)
regards
David
--
***************************************************************** 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
***************************************************************** -- 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 *****************************************************************
![](https://secure.gravatar.com/avatar/25170d7bd06dd4d753053e12888d1bb0.jpg?s=120&d=mm&r=g)
Hi David, I'm submitting this on behalf of Morris Riedel, whose team is working at Juelich in adding VOMS support to UNICORE, and has implemented the client part of the Attribute Exchange Profile. He's also going to be at OGF 22 and willing to help in the interop demo event. Morris is the GIN secretary and has just been participating in preparing a lot of OGF related interop demos at last SC (among which, a VOMS UNICORE interop demo which leverage the attribute exchange profile implementation). Profile being implemented: Attribute Exchange Profile Organisation doing the implementation: FZJ Contact details: Morris Riedel <m.riedel@fz-juelich.de> Short description: VOMS support in UNICORE6. Valerio On Sat, 2007-11-17 at 11:56 +0000, David Chadwick wrote:
Dear WG
I would like to draw up a table of implementations of the 3 protocol profile docs that we have published (XACML, WS-Trust and SAML AA).
The information that would be useful for the group is
Profile being implemented: Organisation doing the implementation: Contact details: Short description:
(the latter to contain such things as status of implementation, any interworking carried out, where software might be obtained etc. Whatever you feel is appropriate for the WG)
regards
David
![](https://secure.gravatar.com/avatar/9317cd6310608b2db2404b844d8b54bd.jpg?s=120&d=mm&r=g)
Hi David and WG, I can report about implementing all currently proposed documents which we consider an important basis for interoperability. Our implementations are at different stages but architecturally confirms to the "Functional Components of Grid Service Provider Authorisation Service Middleware" document. Profile being implemented: XACML Request Context to Obtain an Authorization Decision Organisation doing the implementation: System and Network Engineering (SNE) Group, University of Amsterdam Contact details: Yuri Demchenko <demch@science.uva.nl> Short description: GAAA Toolkit Target project Phosphorus (EU-IST), AAA/AuthZ infrastructure for multidomain Network Resource Provisioning (NRP). Comment: Current implementation uses different model and semantics for Obligations handling, use of the "chronicle" may be considered. Profile being implemented: OGSA Attribute Exchange Profile Organisation doing the implementation: System and Network Engineering (SNE) Group, University of Amsterdam Contact details: Yuri Demchenko <demch@science.uva.nl> Short description: GAAA Toolkit Target project Phosphorus (EU-IST), AAA/AuthZ infrastructure for multidomain Network Resource Provisioning (NRP) that needs to use different attributes local to a network/resource domain. Profile being implemented: Use of WS-Trust and SAML to access a CVS (partly, credentials push model) Organisation doing the implementation: System and Network Engineering (SNE) Group, University of Amsterdam Contact details: Yuri Demchenko <demch@science.uva.nl> Short description: Token Validation Service (TVS), component of the GAAA Toolkit. Target project Phosphorus (EU-IST), AAA/AuthZ infrastructure for multidomain Network Resource Provisioning (NRP), token-based policy/authorisation decision enforcement to access the reserved network resource. Some implementation and development plans and results may be reported later for the gLite Java AuthZ Service (gJAF) but it will depend on the progress. Regards, Yuri David Chadwick wrote:
I would like to draw up a table of implementations of the 3 protocol profile docs that we have published (XACML, WS-Trust and SAML AA).>
Profile being implemented: Organisation doing the implementation: Contact details: Short description:
(the latter to contain such things as status of implementation, any interworking carried out, where software might be obtained etc. Whatever you feel is appropriate for the WG)
![](https://secure.gravatar.com/avatar/6e1526a3d8af0bb09676f1b771810cf4.jpg?s=120&d=mm&r=g)
Hi Yuri in your implementation report you said that you were proposing to handle obligations differently to that proposed in the OGSA Authz XACML spec. Given that this is based on XACML's obligation handling, could you please let the group know how you propose to do it differently. Concerning the chronicle attribute, which was in an early draft of the Authz spec, but is not in the OASIS XACML spec, I discussed this with members of the XACML group, who suggested that it could be incorporated into the URL, thereby remaining conformant to the XACML standard, but potentially increasing the number of URLs significantly. During this discussion it was clear that the XACML group itself had not reached a concensus on the best way to handle the timing of obligations, and some of the group actually supported the inclusion of a chronicle attribute. Others thought timing might need to be more complex still. So it is likely that the XACML group may update their spec in the future in order to better handle the timing of obligations regards David Yuri Demchenko wrote:
Hi David and WG,
I can report about implementing all currently proposed documents which we consider an important basis for interoperability. Our implementations are at different stages but architecturally confirms to the "Functional Components of Grid Service Provider Authorisation Service Middleware" document.
Profile being implemented: XACML Request Context to Obtain an Authorization Decision Organisation doing the implementation: System and Network Engineering (SNE) Group, University of Amsterdam Contact details: Yuri Demchenko <demch@science.uva.nl> Short description: GAAA Toolkit Target project Phosphorus (EU-IST), AAA/AuthZ infrastructure for multidomain Network Resource Provisioning (NRP). Comment: Current implementation uses different model and semantics for Obligations handling, use of the "chronicle" may be considered.
Profile being implemented: OGSA Attribute Exchange Profile Organisation doing the implementation: System and Network Engineering (SNE) Group, University of Amsterdam Contact details: Yuri Demchenko <demch@science.uva.nl> Short description: GAAA Toolkit Target project Phosphorus (EU-IST), AAA/AuthZ infrastructure for multidomain Network Resource Provisioning (NRP) that needs to use different attributes local to a network/resource domain.
Profile being implemented: Use of WS-Trust and SAML to access a CVS (partly, credentials push model) Organisation doing the implementation: System and Network Engineering (SNE) Group, University of Amsterdam Contact details: Yuri Demchenko <demch@science.uva.nl> Short description: Token Validation Service (TVS), component of the GAAA Toolkit. Target project Phosphorus (EU-IST), AAA/AuthZ infrastructure for multidomain Network Resource Provisioning (NRP), token-based policy/authorisation decision enforcement to access the reserved network resource.
Some implementation and development plans and results may be reported later for the gLite Java AuthZ Service (gJAF) but it will depend on the progress.
Regards,
Yuri
David Chadwick wrote:
I would like to draw up a table of implementations of the 3 protocol profile docs that we have published (XACML, WS-Trust and SAML AA).>
Profile being implemented: Organisation doing the implementation: Contact details: Short description:
(the latter to contain such things as status of implementation, any interworking carried out, where software might be obtained etc. Whatever you feel is appropriate for the WG)
-- 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 *****************************************************************
participants (7)
-
Alan Sill
-
David Chadwick
-
Richard Sinnott
-
Tom Scavo
-
Valerio Venturi
-
wz qiang
-
Yuri Demchenko