OGSA-Authz-WG draft meeting minutes: OGF Jan 29 session
Draft notes from today's OGSA-Authz WG meeting. Please send corrections or addition. In particular there were protocols referred to at a couple of points that need exact identification, which are marked with "XXX". Von ---- * Preamble David brought meeting to order Circulated OGF IP sign-in sheet Von volunteers to scribe * Telecon Update Decision: Once every two months, we will take one of the OGSA-WG phone call slots to report to the larger community. Next date will be March 8th. Decision: Telecon dates February 13th March 7th April 3rd April 23rd * Functional Components Doc Latest version is Oct 24th version Outstanding issue: implications of carrying attributes and credentials within the same protocol or within different protocols [XXX pointer?] Outstanding issue: Id vs URL issued raised by Tom Scavo [XXX pointer?] Doc should then be ready for WG final call and progression to AD * Protocol Doc Updates Described 3 protocol 1) PEP-Context Handler: no profile proposed. Maybe the same as protocol #3 if credential equivalent to attributes. 2) Context Handler-CVS: WS-Trust profile, to be written. 3) Context Handler-PDP: proposal XACML request/response protocol proposed [Question raised regarding exactly which protocol is being referred to here. Concerns from Nate that this has been deprecated. XXX pointer?] * Takuyi Mori presentation on NAREGI Authz Service and NAREGI XACML profile Slides will be sent to the email list SAML 2.0 and XACML 2.0 based Uses GT authz framework Profile between Authz service client (in GT4) and Authz CVS Handles VOMS AC's and passes to Authz service Presented mapping of attributes from X.509 EEC/VOMS AC into XACML Resource Attribute Filtering Mechanism (RAFM) - Reference properties, XACML profile has Subject, Resource and Action attributes * VOMS profile Discussed on Oct 16 telecon - minutes on list Meaning of the primary type must be explicit rather than implicit (as currently done via sequence) Awaiting response from VOMS group * Attribute Retrieval Protocol Added as last meeting OASIS profile for SAML - Tom Scavo author * Von Welch resignation as WG chair Those who are interesting in replacing Von should send email to David * Other business Tom Scavo: Do we need mechanism to bind SAML to X.509 (equivalent to VOMS)? David: 2005 X.509 has specification for binding XML to X.509, but doesn't specify XML content Tom Scavo to investigate how these relate. David: VOMS may be moving to a SAML in some way, need to understand this.
Von Welch wrote:
Draft notes from today's OGSA-Authz WG meeting. Please send corrections or addition. In particular there were protocols referred to at a couple of points that need exact identification, which are marked with "XXX".
Von
----
* Preamble David brought meeting to order Circulated OGF IP sign-in sheet Von volunteers to scribe
* Telecon Update
Decision: Once every two months, we will take one of the OGSA-WG phone call slots to report to the larger community. Next date will be March 8th.
Decision: Telecon dates February 13th March 7th April 3rd April 23rd
* Functional Components Doc Latest version is Oct 24th version Outstanding issue: implications of carrying attributes and credentials within the same protocol or within different protocols [XXX pointer?]
"Functional Components of Grid Service Provider Authorisation Service Middleware" available from http://forge.gridforum.org/sf/go/doc13968?nav=1
Outstanding issue: Id vs URL issued raised by Tom Scavo [XXX pointer?] Doc should then be ready for WG final call and progression to AD
* Protocol Doc Updates Described 3 protocol 1) PEP-Context Handler: no profile proposed. Maybe the same as protocol #3 if credential equivalent to attributes.
if credentials can be carried in same field as attributes in the protocol.
2) Context Handler-CVS: WS-Trust profile, to be written
No its Available at http://forge.gridforum.org/sf/go/doc9011?nav=1
3) Context Handler-PDP: proposal XACML request/response protocol proposed [Question raised regarding exactly which protocol is being referred to here. Concerns from Nate that this has been deprecated. XXX pointer?]
the current profile, available from http://forge.gridforum.org/sf/go/doc13681?nav=1 in which the XACML request context is transported to the PDP in a SAML request message. Apparently this OASIS mechanism has been deprecated because it was (wrongly) thought that no-one was using it. We thus may need to reconsider this protocol and use a different wrapper to carry the XACML contexts.
* Takuyi Mori presentation on NAREGI Authz Service and NAREGI XACML profile Slides will be sent to the email list SAML 2.0 and XACML 2.0 based Uses GT authz framework Profile between Authz service client (in GT4) and Authz CVS Handles VOMS AC's and passes to Authz service Presented mapping of attributes from X.509 EEC/VOMS AC into XACML Resource Attribute Filtering Mechanism (RAFM) - Reference properties, XACML profile has Subject, Resource and Action attributes
There is an issue as to how a resource's attributes are obtained by the PEP. If the user submits them to the PEP there is a potential trust issue here, and the attributes will need to validated by the CVS. If the PEP obtains them itself from a local store this is not an issue.
* VOMS profile Discussed on Oct 16 telecon - minutes on list Meaning of the primary type must be explicit rather than implicit (as currently done via sequence) Awaiting response from VOMS group
* Attribute Retrieval Protocol Added as last meeting OASIS profile for SAML - Tom Scavo author
* Von Welch resignation as WG chair Those who are interesting in replacing Von should send email to David
* Other business Tom Scavo: Do we need mechanism to bind SAML to X.509 (equivalent to VOMS)? David: 2005 X.509 has specification for binding XML to X.509, but doesn't specify XML content Tom Scavo to investigate how these relate.
David: VOMS is providing a standard SAML protocol interface for picking up VOMS attributes. A beta is supposed to be ready by April 2007 regards David
-- 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://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************
On Mon, 2007-01-29 at 20:10 +0000, David Chadwick wrote:
* VOMS profile Discussed on Oct 16 telecon - minutes on list Meaning of the primary type must be explicit rather than implicit (as currently done via sequence) Awaiting response from VOMS group What we haven't understood so far is why an explicit primary attribute is needed rather then an implicit one and what needs an eventual change in VOMS AC format would address.
* Attribute Retrieval Protocol Added as last meeting OASIS profile for SAML - Tom Scavo author
* Von Welch resignation as WG chair Those who are interesting in replacing Von should send email to David
* Other business Tom Scavo: Do we need mechanism to bind SAML to X.509 (equivalent to VOMS)? David: 2005 X.509 has specification for binding XML to X.509, but doesn't specify XML content Tom Scavo to investigate how these relate. Shouldn't this be done by SubjectConfirmation? Or are you talking about assertions travelling within X.509 proxies?
David: VOMS is providing a standard SAML protocol interface for picking up VOMS attributes. A beta is supposed to be ready by April 2007 That's correct David. The protocol is that in SAML V2.0 Profiles for X.509 Subject as agreed. We are about to work on the implementation of the protocol and we will eventually inform Tom and the authors about any issue we may have. Hope it won't be too late by that time but we couldn't make it before.
Valerio
On 1/31/07, Valerio Venturi <valerio.venturi@cnaf.infn.it> wrote:
On Mon, 2007-01-29 at 20:10 +0000, David Chadwick wrote:
* Other business Tom Scavo: Do we need mechanism to bind SAML to X.509 (equivalent to VOMS)? David: 2005 X.509 has specification for binding XML to X.509, but doesn't specify XML content Tom Scavo to investigate how these relate. Shouldn't this be done by SubjectConfirmation? Or are you talking about assertions travelling within X.509 proxies?
Yes, the latter. See the following wiki page for some crude thoughts along these lines: https://spaces.internet2.edu/display/GS/X509BindingSAML
David: VOMS is providing a standard SAML protocol interface for picking up VOMS attributes. A beta is supposed to be ready by April 2007 That's correct David. The protocol is that in SAML V2.0 Profiles for X.509 Subject as agreed. We are about to work on the implementation of the protocol and we will eventually inform Tom and the authors about any issue we may have. Hope it won't be too late by that time but we couldn't make it before.
Not too late from my point of view. Valerio, would you mind providing a pointer to the spec you're looking at? There have been many versions and I want to make sure you're looking at the right one. Thanks, Tom
On 1/31/07, Valerio Venturi <valerio.venturi@cnaf.infn.it> wrote:
On Mon, 2007-01-29 at 20:10 +0000, David Chadwick wrote:
* Other business Tom Scavo: Do we need mechanism to bind SAML to X.509 (equivalent to VOMS)? David: 2005 X.509 has specification for binding XML to X.509, but doesn't specify XML content Tom Scavo to investigate how these relate. Shouldn't this be done by SubjectConfirmation? Or are you talking about assertions travelling within X.509 proxies?
Yes, the latter. See the following wiki page for some crude thoughts along these lines:
https://spaces.internet2.edu/display/GS/X509BindingSAML Thanks, we'll have a look at it. However, in our plans, the natural
On Wed, 2007-01-31 at 09:38 -0500, Tom Scavo wrote: format for attributes in X.509 proxies extensions will still be ACs so I don't know if it will be a needs for us.
David: VOMS is providing a standard SAML protocol interface for picking up VOMS attributes. A beta is supposed to be ready by April 2007 That's correct David. The protocol is that in SAML V2.0 Profiles for X.509 Subject as agreed. We are about to work on the implementation of the protocol and we will eventually inform Tom and the authors about any issue we may have. Hope it won't be too late by that time but we couldn't make it before.
Not too late from my point of view. Valerio, would you mind providing a pointer to the spec you're looking at? There have been many versions and I want to make sure you're looking at the right one. http://www.oasis-open.org/committees/document.php?document_id=20000&wg_abbrev=security
Valerio
On 1/31/07, Valerio Venturi <valerio.venturi@cnaf.infn.it> wrote:
On Wed, 2007-01-31 at 09:38 -0500, Tom Scavo wrote:
On 1/31/07, Valerio Venturi <valerio.venturi@cnaf.infn.it> wrote:
Or are you talking about assertions travelling within X.509 proxies?
Yes, the latter. See the following wiki page for some crude thoughts along these lines:
Thanks, we'll have a look at it. However, in our plans, the natural format for attributes in X.509 proxies extensions will still be ACs so I don't know if it will be a needs for us.
Understood.
Valerio, would you mind providing a pointer to the spec you're looking at? There have been many versions and I want to make sure you're looking at the right one. http://www.oasis-open.org/committees/document.php?document_id=20000&wg_abbrev=security
Ah, that's what I thought...you should work from this instead: http://www.oasis-open.org/committees/download.php/21568/sstc-saml2-profiles-... It's not significantly different than the previous one, but it is the current version on the table. Tom
On Wed, 2007-01-31 at 10:58 -0500, Tom Scavo wrote:
On 1/31/07, Valerio Venturi <valerio.venturi@cnaf.infn.it> wrote:
On Wed, 2007-01-31 at 09:38 -0500, Tom Scavo wrote:
On 1/31/07, Valerio Venturi <valerio.venturi@cnaf.infn.it> wrote:
Or are you talking about assertions travelling within X.509 proxies?
Yes, the latter. See the following wiki page for some crude thoughts along these lines:
Thanks, we'll have a look at it. However, in our plans, the natural format for attributes in X.509 proxies extensions will still be ACs so I don't know if it will be a needs for us.
Understood.
Valerio, would you mind providing a pointer to the spec you're looking at? There have been many versions and I want to make sure you're looking at the right one. http://www.oasis-open.org/committees/document.php?document_id=20000&wg_abbrev=security
Ah, that's what I thought...you should work from this instead:
http://www.oasis-open.org/committees/download.php/21568/sstc-saml2-profiles-...
It's not significantly different than the previous one, but it is the current version on the table.
Where are you notifying new versions? It looks like google it's not reliable. :-) Valerio
On 1/31/07, Valerio Venturi <valerio.venturi@cnaf.infn.it> wrote:
On Wed, 2007-01-31 at 10:58 -0500, Tom Scavo wrote:
http://www.oasis-open.org/committees/download.php/21568/sstc-saml2-profiles-...
It's not significantly different than the previous one, but it is the current version on the table.
Where are you notifying new versions? It looks like google it's not reliable. :-)
Sorry about that. It's listed on the GridShib Documents page: http://gridshib.globus.org/documents.php This is the best place to keep track of this (and other) such documents. For instance, the SAML V1.1 version of the same document is listed there as well. Thanks for your interest, Tom
Valerio Venturi wrote:
On Mon, 2007-01-29 at 20:10 +0000, David Chadwick wrote:
* VOMS profile Discussed on Oct 16 telecon - minutes on list Meaning of the primary type must be explicit rather than implicit (as currently done via sequence) Awaiting response from VOMS group What we haven't understood so far is why an explicit primary attribute is needed rather then an implicit one and what needs an eventual change in VOMS AC format would address.
Hi Valerio The OGSA Authz group is not saying that an explicit primary attribute is needed. It is saying that if you have a set of attributes, then they are all the same, and should be treated as all being the same, and you cannot imply something special for the first one in the list, since the order may not be maintained by intermediate processing nodes, or even by software modules within one system. So, if you have a requirement that one attribute value in a set is special, then this needs to be explicitly signaled in the protocol. One way of doing this is by removing it from the set, and explicitly flagging it as a different type of attribute. There is a good well documented example of this already in the EduPerson schema.
* Attribute Retrieval Protocol Added as last meeting OASIS profile for SAML - Tom Scavo author
* Von Welch resignation as WG chair Those who are interesting in replacing Von should send email to David
* Other business Tom Scavo: Do we need mechanism to bind SAML to X.509 (equivalent to VOMS)? David: 2005 X.509 has specification for binding XML to X.509, but doesn't specify XML content Tom Scavo to investigate how these relate. Shouldn't this be done by SubjectConfirmation? Or are you talking about assertions travelling within X.509 proxies?
We are talking about passing XML assertions or other XML content in an X.509 attribute within an X.509 certificate.
David: VOMS is providing a standard SAML protocol interface for picking up VOMS attributes. A beta is supposed to be ready by April 2007 That's correct David. The protocol is that in SAML V2.0 Profiles for X.509 Subject as agreed. We are about to work on the implementation of the protocol and we will eventually inform Tom and the authors about any issue we may have. Hope it won't be too late by that time but we couldn't make it before.
great stuff David
Valerio
-- ***************************************************************** 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://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************
Hi David, David Chadwick wrote:
Valerio Venturi wrote:
On Mon, 2007-01-29 at 20:10 +0000, David Chadwick wrote:
* VOMS profile Discussed on Oct 16 telecon - minutes on list Meaning of the primary type must be explicit rather than implicit (as currently done via sequence) Awaiting response from VOMS group
What we haven't understood so far is why an explicit primary attribute is needed rather then an implicit one and what needs an eventual change in VOMS AC format would address.
Hi Valerio
The OGSA Authz group is not saying that an explicit primary attribute is needed. It is saying that if you have a set of attributes, then they are all the same, and should be treated as all being the same, and you cannot imply something special for the first one in the list, since the order may not be maintained by intermediate processing nodes, or even by software modules within one system.
Ahhhh.... I think that there is a misunderstanding here. It is certainly true that a single Attribute object may contain a SET OF AttributeValue, thus creating the problem you just described. However, the VOMS attribute is defined as such, as you may also see in the profile: name : voms-attribute OID : { voms 4 } syntax : IetfAttrSyntax values : Multiple not allowed This means that only one value may be present in there. The different FQAN are then encoded in that single value in a sequence. Evaluating nodes are so required to keep the order to comply with ASN.1 decoding rules, thus eliminating the issue. Ciao, Vincenzo
Hi Vincenzo If something is defined as a sequence, then order is important and it should be maintained. So it would appear that you are doing things correctly in your implementation. Whether it is the best way of doing it or not, is open to debate. But it is your implementation and your choice regards David Vincenzo Ciaschini wrote:
Hi David,
David Chadwick wrote:
Valerio Venturi wrote:
On Mon, 2007-01-29 at 20:10 +0000, David Chadwick wrote:
* VOMS profile Discussed on Oct 16 telecon - minutes on list Meaning of the primary type must be explicit rather than implicit (as currently done via sequence) Awaiting response from VOMS group
What we haven't understood so far is why an explicit primary attribute is needed rather then an implicit one and what needs an eventual change in VOMS AC format would address.
Hi Valerio
The OGSA Authz group is not saying that an explicit primary attribute is needed. It is saying that if you have a set of attributes, then they are all the same, and should be treated as all being the same, and you cannot imply something special for the first one in the list, since the order may not be maintained by intermediate processing nodes, or even by software modules within one system.
Ahhhh.... I think that there is a misunderstanding here. It is certainly true that a single Attribute object may contain a SET OF AttributeValue, thus creating the problem you just described. However, the VOMS attribute is defined as such, as you may also see in the profile:
name : voms-attribute OID : { voms 4 } syntax : IetfAttrSyntax values : Multiple not allowed
This means that only one value may be present in there.
The different FQAN are then encoded in that single value in a sequence.
Evaluating nodes are so required to keep the order to comply with ASN.1 decoding rules, thus eliminating the issue.
Ciao, Vincenzo
-- ***************************************************************** 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://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************
On Wed, 31 Jan 2007 17:08:37 +0100 Vincenzo Ciaschini <vincenzo.ciaschini@cnaf.infn.it> wrote:
Hi David,
David Chadwick wrote:
Valerio Venturi wrote:
On Mon, 2007-01-29 at 20:10 +0000, David Chadwick wrote:
* VOMS profile Discussed on Oct 16 telecon - minutes on list Meaning of the primary type must be explicit rather than implicit (as currently done via sequence) Awaiting response from VOMS group
What we haven't understood so far is why an explicit primary attribute is needed rather then an implicit one and what needs an eventual change in VOMS AC format would address.
Hi Valerio
The OGSA Authz group is not saying that an explicit primary attribute is needed. It is saying that if you have a set of attributes, then they are all the same, and should be treated as all being the same, and you cannot imply something special for the first one in the list, since the order may not be maintained by intermediate processing nodes, or even by software modules within one system.
Ahhhh.... I think that there is a misunderstanding here. It is certainly true that a single Attribute object may contain a SET OF AttributeValue, thus creating the problem you just described. However, the VOMS attribute is defined as such, as you may also see in the profile:
name : voms-attribute OID : { voms 4 } syntax : IetfAttrSyntax values : Multiple not allowed
This means that only one value may be present in there.
The different FQAN are then encoded in that single value in a sequence.
Evaluating nodes are so required to keep the order to comply with ASN.1 decoding rules, thus eliminating the issue.
Ciao, Vincenzo
Preserving sequences seems like a tenuous mechanism to flag an attribute value when there are options available like flagging it explicitly. "It would be nice" if the intermediary could translate those FQANs into other representations than ASN.1, though, and not worry about order. For example in GT4.1, we'd like to throw the attributes one by one into a bag of attributes about the client (the bag being contributed to by many attribute sources) -- David's "software modules within one system" point. Another example is converting the FQANs into multi-valued SAML attributes -- intermediary processing example. I'm not saying this is some hard design principle that "must" be ahered to, ultimately if VOMS won't change then people will just need to continue adapting to its inner workings if they want to preserve its primary attribute semantics. Tim
Hi Von, David, Please find my slides in the attachement.
* Takuyi Mori presentation on NAREGI Authz Service and NAREGI XACML
Please correct my name to "Takuya Mori". Thank you,
profile Slides will be sent to the email list SAML 2.0 and XACML 2.0 based Uses GT authz framework Profile between Authz service client (in GT4) and Authz CVS Handles VOMS AC's and passes to Authz service Presented mapping of attributes from X.509 EEC/VOMS AC into XACML Resource Attribute Filtering Mechanism (RAFM) - Reference properties, XACML profile has Subject, Resource and Action attributes
There is an issue as to how a resource's attributes are obtained by the PEP. If the user submits them to the PEP there is a potential trust issue here, and the attributes will need to validated by the CVS. If the PEP obtains them itself from a local store this is not an issue.
Yes, this is an open issue. I'll write the detail on the RAFM and send it to the list. ---- Takuya Mori moritaku@bx.jp.nec.com / tk-mori@isd.nec.co.jp System Platform Software Development Division NEC Corporation, Tokyo Japan
Hi Takuya I have uploaded them to the forge at http://forge.gridforum.org/sf/docman/do/listDocuments/projects.ogsa-authz/do... regards David Takuya Mori wrote:
Hi Von, David,
Please find my slides in the attachement.
* Takuyi Mori presentation on NAREGI Authz Service and NAREGI XACML
Please correct my name to "Takuya Mori". Thank you,
profile Slides will be sent to the email list SAML 2.0 and XACML 2.0 based Uses GT authz framework Profile between Authz service client (in GT4) and Authz CVS Handles VOMS AC's and passes to Authz service Presented mapping of attributes from X.509 EEC/VOMS AC into XACML Resource Attribute Filtering Mechanism (RAFM) - Reference properties, XACML profile has Subject, Resource and Action attributes There is an issue as to how a resource's attributes are obtained by the PEP. If the user submits them to the PEP there is a potential trust issue here, and the attributes will need to validated by the CVS. If the PEP obtains them itself from a local store this is not an issue.
Yes, this is an open issue. I'll write the detail on the RAFM and send it to the list.
---- Takuya Mori moritaku@bx.jp.nec.com / tk-mori@isd.nec.co.jp System Platform Software Development Division NEC Corporation, Tokyo Japan
-- ***************************************************************** 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://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************
Pointer included below. On 1/29/07, Von Welch <vwelch@ncsa.uiuc.edu> wrote:
Draft notes from today's OGSA-Authz WG meeting. Please send corrections or addition. In particular there were protocols referred to at a couple of points that need exact identification, which are marked with "XXX".
Von
----
* Preamble David brought meeting to order Circulated OGF IP sign-in sheet Von volunteers to scribe
* Telecon Update
Decision: Once every two months, we will take one of the OGSA-WG phone call slots to report to the larger community. Next date will be March 8th.
Decision: Telecon dates February 13th March 7th April 3rd April 23rd
* Functional Components Doc Latest version is Oct 24th version Outstanding issue: implications of carrying attributes and credentials within the same protocol or within different protocols [XXX pointer?] Outstanding issue: Id vs URL issued raised by Tom Scavo [XXX pointer?]
http://www.ogf.org/pipermail/ogsa-authz-wg/2006-November/000242.html
Doc should then be ready for WG final call and progression to AD
* Protocol Doc Updates Described 3 protocol 1) PEP-Context Handler: no profile proposed. Maybe the same as protocol #3 if credential equivalent to attributes. 2) Context Handler-CVS: WS-Trust profile, to be written. 3) Context Handler-PDP: proposal XACML request/response protocol proposed [Question raised regarding exactly which protocol is being referred to here. Concerns from Nate that this has been deprecated. XXX pointer?]
* Takuyi Mori presentation on NAREGI Authz Service and NAREGI XACML profile Slides will be sent to the email list SAML 2.0 and XACML 2.0 based Uses GT authz framework Profile between Authz service client (in GT4) and Authz CVS Handles VOMS AC's and passes to Authz service Presented mapping of attributes from X.509 EEC/VOMS AC into XACML Resource Attribute Filtering Mechanism (RAFM) - Reference properties, XACML profile has Subject, Resource and Action attributes
* VOMS profile Discussed on Oct 16 telecon - minutes on list Meaning of the primary type must be explicit rather than implicit (as currently done via sequence) Awaiting response from VOMS group
* Attribute Retrieval Protocol Added as last meeting OASIS profile for SAML - Tom Scavo author
* Von Welch resignation as WG chair Those who are interesting in replacing Von should send email to David
* Other business Tom Scavo: Do we need mechanism to bind SAML to X.509 (equivalent to VOMS)? David: 2005 X.509 has specification for binding XML to X.509, but doesn't specify XML content Tom Scavo to investigate how these relate. David: VOMS may be moving to a SAML in some way, need to understand this.
-- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
participants (7)
-
David Chadwick -
Takuya Mori -
Tim Freeman -
Tom Scavo -
Valerio Venturi -
Vincenzo Ciaschini -
Von Welch