Re: [OGSA-AUTHZ] Teleconference
Hi Blair Don't worry. Your input at the meeting will be sufficient. Some people are not able to attend GGF, so the telecom is much more important to them than to yourself. regards David. Blair Dillaway wrote:
David,
While I'd like to participate in this call, I can't make the scheduled time. I do have some feedback on the revised charter document. I can provide that at GGF next week.
Regards, Blair Dillaway
-----Original Message----- From: owner-ogsa-authz@ggf.org [mailto:owner-ogsa-authz@ggf.org] On Behalf Of David Chadwick Sent: Friday, September 01, 2006 2:37 PM To: ogsa Authz Subject: [OGSA-AUTHZ] Teleconference
Dear WG members
Now that the holidays are over, I am proposing to hold a teleconference next week on either Thursday 7 Sept or Friday 8th Sept to discuss the documents currently on the table. Can you please indicate which day you prefer.
This teleconference will give people who are not attending the next GGF meeting to have their say prior to the meeting in Washington the following week. I know that Yuri has a number of issues he wants to discuss.
The time will be 2pm UK, 3pm Europe, 11pm Tokyo, 9am New York, 6am California.
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://sec.cs.kent.ac.uk 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://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************
Hi David and All, I will not be able to attend GGF, so it is important for me to present and discuss some issues related to current OGSA-AUTHZ documents. A) Document "Functional Components of Grid Service Provider Authorisation Service Middleware" https://forge.gridforum.org/sf/go/doc13724?nav=1 This is very useful document but in current version it looks rather like justification for CVS and less reflects other possible implementations/models for AuthZ service 1) Section 5 and diagrams may look too PERMIS or "attributes push/pull" model biased. All 4 interaction models on Fig. 1-4 use unclear functionality of PEP or PDP that decides to call to CVS. It would be useful to define it e.g. as a ContextHandler (CtxHandler) in XACML style. This will not affect CVS justification because of XACML doesn't define validation related functions at all but will give more connection to XACML. Defining CtxHandler functionality will give us more flexibility in defining other interactions between PEP and PDP. So, functionally (and graphically/topologically) I would define CtxHandler as a module via which external to PEP-PDP communication services are called out. 2) I would also clarify the use of "Authenticated Name" and why User AuthN is inside the PEP Indeed we need to use requestor's "Authenticated Name" but in which way: as authentic or as valid :-) How it is ensured in this model? 3) The document uses words "push" and "pull" in relation to attributes. At the same time this document GFD-I.038 "Conceptual Grid Authorization Framework and Classification" defines also authorisation decision "push" and "pull" models. Does CVS work for both "push" and "pull" AuthZ models? To cut a long story short and to avoid further and future confusion for readers who are not deeply involved in such (rather historical) discussion, I would propose not to use these words in this and other OGSA-AUTHZ documents except in introduction or overview sections ;-) If we can not avoid this discussion, I would be ready to provide other argumentation. 3) There is one important functionality that seems mission from the "Functional Components of Grid Service Provider Authorisation Service Middleware" - this is AuthZ session management in a simple meaning and more extended. What if PDP will return "intermediate" state like in XACML? In *authorisation* push scenario a requestor provides set of capabilities/attributes based on preliminary AuthZ decision which should definitely have validity period. How we process/validate this scenario? Do we have means to revoke AuthZ session related credentials? 3) on Fig. 5 it is not clear what is "Credential Authenticator" and "Credential Decoder". If I understood their functionality correctly, I would prefer "Credential Verifier" and "Credential Resolver" Also in relation to this picture we need to clarify relation between terms "attributes" and "credentials". B) Document "CVS Requirements" https://forge.gridforum.org/sf/go/doc13701?nav=1 1) some more rather generic CVS requirements are missing, like - CVS can be called from PEP and PDP, or via CtxHandler module - what kind of messages/interface used - what type of policies are suggested and if some existing can be used - accepted creds/attrs formats 2) Additionally, should we define CVS operations on credentials/attributes? CVS caching capability? 3) this document also should explain CVS positioning to STS and also to GT4-AuthZ and GAAA-AuthZ 4) from the (security) middleware developers point of view, it would be useful to explain/put some requirements how the CVS can be integrated into overall AuthZ service or infrastructure, in sense of configuration of namespaces, CA/Trust anchors, trusted authorities, etc. These may be many issues but I see them as important if I would try to implement proposed CVS functionality as a part of the AuthZ service, especially for dynamic services and multidomain scenarios. We can discuss some of these issues later today. Yuri David Chadwick wrote:
Hi Blair
Don't worry. Your input at the meeting will be sufficient. Some people are not able to attend GGF, so the telecom is much more important to them than to yourself.
regards
David.
Blair Dillaway wrote:
David,
While I'd like to participate in this call, I can't make the scheduled time. I do have some feedback on the revised charter document. I can provide that at GGF next week.
Regards, Blair Dillaway
-----Original Message----- From: owner-ogsa-authz@ggf.org [mailto:owner-ogsa-authz@ggf.org] On Behalf Of David Chadwick Sent: Friday, September 01, 2006 2:37 PM To: ogsa Authz Subject: [OGSA-AUTHZ] Teleconference
Dear WG members
Now that the holidays are over, I am proposing to hold a teleconference next week on either Thursday 7 Sept or Friday 8th Sept to discuss the documents currently on the table. Can you please indicate which day you prefer.
This teleconference will give people who are not attending the next GGF meeting to have their say prior to the meeting in Washington the following week. I know that Yuri has a number of issues he wants to discuss.
The time will be 2pm UK, 3pm Europe, 11pm Tokyo, 9am New York, 6am California.
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://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5
*****************************************************************
Hi Yuri thanks for your very helpful comments, which we will discuss in more detail later today. Could I ask one favour from you please. Could you draw a diagram showing your proposed context handler module and how it may interact with PDP and PEP functionalities, in authz push and pull and itermediate modes and circulate this to the list. I often find that a diagram is easier to visualise than simply a bunch of words. Talk to you later today regards David Yuri Demchenko wrote:
Hi David and All,
I will not be able to attend GGF, so it is important for me to present and discuss some issues related to current OGSA-AUTHZ documents.
A) Document "Functional Components of Grid Service Provider Authorisation Service Middleware" https://forge.gridforum.org/sf/go/doc13724?nav=1
This is very useful document but in current version it looks rather like justification for CVS and less reflects other possible implementations/models for AuthZ service
1) Section 5 and diagrams may look too PERMIS or "attributes push/pull" model biased.
All 4 interaction models on Fig. 1-4 use unclear functionality of PEP or PDP that decides to call to CVS.
It would be useful to define it e.g. as a ContextHandler (CtxHandler) in XACML style. This will not affect CVS justification because of XACML doesn't define validation related functions at all but will give more connection to XACML.
Defining CtxHandler functionality will give us more flexibility in defining other interactions between PEP and PDP.
So, functionally (and graphically/topologically) I would define CtxHandler as a module via which external to PEP-PDP communication services are called out.
2) I would also clarify the use of "Authenticated Name" and why User AuthN is inside the PEP
Indeed we need to use requestor's "Authenticated Name" but in which way: as authentic or as valid :-) How it is ensured in this model?
3) The document uses words "push" and "pull" in relation to attributes.
At the same time this document GFD-I.038 "Conceptual Grid Authorization Framework and Classification" defines also authorisation decision "push" and "pull" models.
Does CVS work for both "push" and "pull" AuthZ models?
To cut a long story short and to avoid further and future confusion for readers who are not deeply involved in such (rather historical) discussion, I would propose not to use these words in this and other OGSA-AUTHZ documents except in introduction or overview sections ;-)
If we can not avoid this discussion, I would be ready to provide other argumentation.
3) There is one important functionality that seems mission from the "Functional Components of Grid Service Provider Authorisation Service Middleware" - this is AuthZ session management in a simple meaning and more extended.
What if PDP will return "intermediate" state like in XACML?
In *authorisation* push scenario a requestor provides set of capabilities/attributes based on preliminary AuthZ decision which should definitely have validity period. How we process/validate this scenario? Do we have means to revoke AuthZ session related credentials?
3) on Fig. 5 it is not clear what is "Credential Authenticator" and "Credential Decoder". If I understood their functionality correctly, I would prefer "Credential Verifier" and "Credential Resolver"
Also in relation to this picture we need to clarify relation between terms "attributes" and "credentials".
B) Document "CVS Requirements" https://forge.gridforum.org/sf/go/doc13701?nav=1
1) some more rather generic CVS requirements are missing, like
- CVS can be called from PEP and PDP, or via CtxHandler module - what kind of messages/interface used - what type of policies are suggested and if some existing can be used - accepted creds/attrs formats
2) Additionally, should we define CVS operations on credentials/attributes? CVS caching capability?
3) this document also should explain CVS positioning to STS and also to GT4-AuthZ and GAAA-AuthZ
4) from the (security) middleware developers point of view, it would be useful to explain/put some requirements how the CVS can be integrated into overall AuthZ service or infrastructure, in sense of configuration of namespaces, CA/Trust anchors, trusted authorities, etc.
These may be many issues but I see them as important if I would try to implement proposed CVS functionality as a part of the AuthZ service, especially for dynamic services and multidomain scenarios.
We can discuss some of these issues later today.
Yuri
David Chadwick wrote:
Hi Blair
Don't worry. Your input at the meeting will be sufficient. Some people are not able to attend GGF, so the telecom is much more important to them than to yourself.
regards
David.
Blair Dillaway wrote:
David,
While I'd like to participate in this call, I can't make the scheduled time. I do have some feedback on the revised charter document. I can provide that at GGF next week.
Regards, Blair Dillaway
-----Original Message----- From: owner-ogsa-authz@ggf.org [mailto:owner-ogsa-authz@ggf.org] On Behalf Of David Chadwick Sent: Friday, September 01, 2006 2:37 PM To: ogsa Authz Subject: [OGSA-AUTHZ] Teleconference
Dear WG members
Now that the holidays are over, I am proposing to hold a teleconference next week on either Thursday 7 Sept or Friday 8th Sept to discuss the documents currently on the table. Can you please indicate which day you prefer.
This teleconference will give people who are not attending the next GGF meeting to have their say prior to the meeting in Washington the following week. I know that Yuri has a number of issues he wants to discuss.
The time will be 2pm UK, 3pm Europe, 11pm Tokyo, 9am New York, 6am California.
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://sec.cs.kent.ac.uk 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://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************
David, I drafted such a picture to which we can add credentials/attributes related labels or messages like on your diagrams. As about AuthN related information, I would rather put it into general AuthZ context. In some cases we probably need to avoid provide user Authenticated Name and use AuthN token because of privacy issues. Yuri David Chadwick wrote:
Hi Yuri
thanks for your very helpful comments, which we will discuss in more detail later today. Could I ask one favour from you please. Could you draw a diagram showing your proposed context handler module and how it may interact with PDP and PEP functionalities, in authz push and pull and itermediate modes and circulate this to the list. I often find that a diagram is easier to visualise than simply a bunch of words.
Talk to you later today
regards
David
Yuri Demchenko wrote:
Hi David and All,
I will not be able to attend GGF, so it is important for me to present and discuss some issues related to current OGSA-AUTHZ documents.
A) Document "Functional Components of Grid Service Provider Authorisation Service Middleware" https://forge.gridforum.org/sf/go/doc13724?nav=1
This is very useful document but in current version it looks rather like justification for CVS and less reflects other possible implementations/models for AuthZ service
1) Section 5 and diagrams may look too PERMIS or "attributes push/pull" model biased.
All 4 interaction models on Fig. 1-4 use unclear functionality of PEP or PDP that decides to call to CVS.
It would be useful to define it e.g. as a ContextHandler (CtxHandler) in XACML style. This will not affect CVS justification because of XACML doesn't define validation related functions at all but will give more connection to XACML.
Defining CtxHandler functionality will give us more flexibility in defining other interactions between PEP and PDP.
So, functionally (and graphically/topologically) I would define CtxHandler as a module via which external to PEP-PDP communication services are called out.
2) I would also clarify the use of "Authenticated Name" and why User AuthN is inside the PEP
Indeed we need to use requestor's "Authenticated Name" but in which way: as authentic or as valid :-) How it is ensured in this model?
3) The document uses words "push" and "pull" in relation to attributes.
At the same time this document GFD-I.038 "Conceptual Grid Authorization Framework and Classification" defines also authorisation decision "push" and "pull" models.
Does CVS work for both "push" and "pull" AuthZ models?
To cut a long story short and to avoid further and future confusion for readers who are not deeply involved in such (rather historical) discussion, I would propose not to use these words in this and other OGSA-AUTHZ documents except in introduction or overview sections ;-)
If we can not avoid this discussion, I would be ready to provide other argumentation.
3) There is one important functionality that seems mission from the "Functional Components of Grid Service Provider Authorisation Service Middleware" - this is AuthZ session management in a simple meaning and more extended.
What if PDP will return "intermediate" state like in XACML?
In *authorisation* push scenario a requestor provides set of capabilities/attributes based on preliminary AuthZ decision which should definitely have validity period. How we process/validate this scenario? Do we have means to revoke AuthZ session related credentials?
3) on Fig. 5 it is not clear what is "Credential Authenticator" and "Credential Decoder". If I understood their functionality correctly, I would prefer "Credential Verifier" and "Credential Resolver"
Also in relation to this picture we need to clarify relation between terms "attributes" and "credentials".
B) Document "CVS Requirements" https://forge.gridforum.org/sf/go/doc13701?nav=1
1) some more rather generic CVS requirements are missing, like
- CVS can be called from PEP and PDP, or via CtxHandler module - what kind of messages/interface used - what type of policies are suggested and if some existing can be used - accepted creds/attrs formats
2) Additionally, should we define CVS operations on credentials/attributes? CVS caching capability?
3) this document also should explain CVS positioning to STS and also to GT4-AuthZ and GAAA-AuthZ
4) from the (security) middleware developers point of view, it would be useful to explain/put some requirements how the CVS can be integrated into overall AuthZ service or infrastructure, in sense of configuration of namespaces, CA/Trust anchors, trusted authorities, etc.
These may be many issues but I see them as important if I would try to implement proposed CVS functionality as a part of the AuthZ service, especially for dynamic services and multidomain scenarios.
We can discuss some of these issues later today.
Yuri
David Chadwick wrote:
Hi Blair
Don't worry. Your input at the meeting will be sufficient. Some people are not able to attend GGF, so the telecom is much more important to them than to yourself.
regards
David.
Blair Dillaway wrote:
David,
While I'd like to participate in this call, I can't make the scheduled time. I do have some feedback on the revised charter document. I can provide that at GGF next week.
Regards, Blair Dillaway
-----Original Message----- From: owner-ogsa-authz@ggf.org [mailto:owner-ogsa-authz@ggf.org] On Behalf Of David Chadwick Sent: Friday, September 01, 2006 2:37 PM To: ogsa Authz Subject: [OGSA-AUTHZ] Teleconference
Dear WG members
Now that the holidays are over, I am proposing to hold a teleconference next week on either Thursday 7 Sept or Friday 8th Sept to discuss the documents currently on the table. Can you please indicate which day you prefer.
This teleconference will give people who are not attending the next GGF meeting to have their say prior to the meeting in Washington the following week. I know that Yuri has a number of issues he wants to discuss.
The time will be 2pm UK, 3pm Europe, 11pm Tokyo, 9am New York, 6am California.
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://sec.cs.kent.ac.uk 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
participants (2)
-
David Chadwick -
Yuri Demchenko