Hi Tom thanks for your detailed comments. I am now updating the document to reflect them. Questions/comments that I want to make are: i) why did you delete Identity Provider from being synonymous with Attribute Authority? If you think they are not technically equivalent can you say why. ii) I suggest changing Credential to Authorisation Credential, because as you point out, Credentials are a superset of signed attribute assertions. iii) concerning the word valid, in 'valid (authorisation) credential', it is not overloaded, since this definition is saying precisely what it means. It is in fact the equivalent in authorisation terms to that of a valid PKC in authentication terms. iv) you ask how the CIS is different from an AA. They are clearly related. An AA is the authority behind the attribute assertions that are released, and it does not have to sign the attribute assertions that are issued. A CIS is a service of an AA, and it does have to sign the assertions. In the grid we are only interested with digitally signed tokens (not symmetrically encrypted ones, MACed ones, or unsigned ones). So we introduce the CIS to show that it is signed attribute assertions that we are concerned with, and the CIS is the service of the AA that does this. We also need to have the converse validation service to the issuing service, hence the CVS. If we replace CIS by AA, then we should also replace CVS, perhaps by AVS. v) I think its useful to keep the MS STS terminology in the document since some readers may already be familiar with this concept, and it gives them a handle on our terminology. Its also good to relate different terms together when they are talking about the same conceptual entities. This helps people figure out how all these disparate terms fit together. (which is related to point i) above) vi) you asked "You’ve used the terms “application independent component”, “application independent service”, and “application independent policy engine.” Can this new terminology be consolidated?" Clearly the policy engine is a subset of the possible services so I dont see any consolidation here. But we could replace component by service, so I have done this. vii) You say about the text 'A user is issued with authorisation credentials by the Credential Issuing Service' "This model description assumes that the presenter of the credentials is the subject". It wasnt meant to. It was meant to imply "Credentials are issued in which the user is the holder/subject" but not say anything about who the requestor or recipient of the credentials were. I have updated the text appropriately. I will issue a new version soon regards David Tom Scavo wrote:

Attached is a modified version of the document "Functional Components of Grid Service Provider Authorisation Service Middleware." I corrected a few things, mostly minor, but the bulk of my comments have to do with terminology.

Tom Scavo NCSA

On 10/31/07, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:

...

Dear All

I have just uploaded the updated the XACML and WS-Trust specs as described at the OGF21 meeting to source forge. I have also updated the architecture document to reflect the latest changes. Pointers to the latest 4 docs are in my other email to Tom. The next task is to homogenise the terminology so that they use consistent terminology throughout the entire set.

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 *****************************************************************

Hi Tom thanks for your input Tom Scavo wrote:

On Nov 28, 2007 1:38 PM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:

...

i) why did you delete Identity Provider from being synonymous with Attribute Authority? If you think they are not technically equivalent can you say why.

An identity provider manages identity information for principals (users).

But identity is simply a set of attributes isnt it? An attribute authority asserts attributes about a subject. And one such attribute could be the user's DN, another could be his address or his mothers maiden name. So as a minimum there is a clear overlap between the IDP and AA, even if they are not synonymous.

The latter is what you want, I think. In any event, the term "identity provider" is not used in this document, so it need not be defined.

I could go along with that, except that Shibboleth used to have AAs in its documentation, then it changed them into IdPs, so if we only mention AAs, it will make it more difficult for readers to relate our document to other ones that mention IdPs. This is one reason why I wanted to include both and show the relationship between them.

...

ii) I suggest changing Credential to Authorisation Credential, because as you point out, Credentials are a superset of signed attribute assertions.

A credential is information that is transferred from one entity to another entity to establish a claimed identity. See:

http://www.itu.int/rec/T-REC-X.800-199103-I/en

So when I think of "credential," I think of authentication. Rather than overload the word "credential," I believe it's better to use the term "signed attribute assertion," but it's your call.

Since an identity attribute is just one type of attribute, then it logically follows that a signed identity attribute, which you are presumably happy to call a credential, is just one type of credential. Thus we can have authentication credentials and authorisation credentials, and both are signed attribute assertions, are they not?

...

iv) you ask how the CIS is different from an AA. They are clearly related. An AA is the authority behind the attribute assertions that are released, and it does not have to sign the attribute assertions that are issued. A CIS is a service of an AA, and it does have to sign the assertions.

That's not enough distinction to warrant a new term, I believe.

However, Microsoft have coined the term Security Token Service for the service that provides both the CIS function and the CVS function. I think this is too general, since it does not say what type of security token service it provides. Not all STSs will be CISs, and not all will be CVSs. This is why I think we need to separate the STS down into its component functionalities.

...

In the grid we are only interested with digitally signed tokens (not symmetrically encrypted ones, MACed ones, or unsigned ones).

I disagree. Our implementation, for example, does not require signed assertions. It requires mutual authentication, yes, but message-level security is but one way to achieve that.

So do you implement zero proof symmetric encryption methods for mutual authentication?

...

So we introduce the CIS to show that it is signed attribute assertions that we are concerned with, and the CIS is the service of the AA that does this. We also need to have the converse validation service to the issuing service, hence the CVS. If we replace CIS by AA, then we should also replace CVS, perhaps by AVS.

I'm afraid I don't understand your point. In any event, the use of the word "credential" is misleading, I think. On the other hand, the word "attribute" is well understood, so why not use that?

Because we need to differentiate between an entity having an attribute, a random (unprovable) assertion that an entity possesses an attribute, and a signed (believable) assertion that an entity possesses an attribute. It is the job of the authorisation infrastructure to disentangle these, and to be able to tell the PDP that this entity has these attributes, give a set of unsigned and signed attribute assertions. Do you appreciate the difference between these three elements? Giving each of these elements different names, and giving names to the functions that provide and validate these elements, seems to be a useful thing to do in my opinion. This is why we have introduced (authorisation) credential, CIS and CVS to be more precise in our terminology and to indicate what elements we are actually talking about. Personally I think many people are confused about the differences between these three elements (heck many people are confused between identification, authentication and authorisation!)

...

v) I think its useful to keep the MS STS terminology in the document since some readers may already be familiar with this concept, and it gives them a handle on our terminology. Its also good to relate different terms together when they are talking about the same conceptual entities. This helps people figure out how all these disparate terms fit together. (which is related to point i) above)

There already is a section on WS-Trust and the STS, which is fine. I don't think you need to add confusing parenthetical remarks in the definitions, however. Indeed, the phrase "synonymous with the validation service of Microsoft's Security Token Service" is false, since a CVS/CIS is not an STS.

Well I think it is, since an STS has three functions, token issuing, token validation and token exchange, where the latter is a combination of the two former functions. regards David

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 *****************************************************************