[David, looks like you neeed to update your subscribed address - Von] - Date: Tue, 15 Mar 2005 05:56:43 +0000 From: David Chadwick <d.w.chadwick@kent.ac.uk> Organization: University of Kent User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) To: Takuya Mori <moritaku@bx.jp.nec.com> Cc: ogsa-authz@gridforum.org Subject: Re: [OGSA-AUTHZ] SAML AuthZ Service Document Comments Hi Takuya these are good questions. Answers below. Takuya Mori wrote:

Hi All,

Please find my comments on the SAML AuthZ Service Document in the below:

1. 5.1 Element <ExtendedAuthorizationDecisionQuery> Request Signed Element - How the client should behave if it gets unsigned response although it has requested signed one?

The spec says that the response SHOULD be signed. We have two choices in my opinion. Either 1. change SHOULD to MUST then it is clear that an unsigned response must be rejected as violating the protocol 2. Add a clause to the end of current paragraph along the following lines "in which case it is a local matter how the requestor deals with the response" Whilst I dont like the second option, I suggest this is what was intended by the original specification.

- Does a client has a free choice for the behavior? ie. A client may ignore the response if it isn't signed even if it has requested a signed response.

yes correct.

2. 6.1.1 NameIdentifier Element - the NameQualifier element is open for the use by applications? IMO, it is good to make it open for application usage

Since we dont say anything about the NameQualifier element, but say "is unchanged from the SAML specification" then you have to consult the SAML spec to determine its usage.

3. 6.1.2 SubjectConfirmation Element - Does the confirmationMethod still be set to http://www.gridforum.org/ogsa-authz/saml/2004/01/am/gsi? even if the subject confirmation method contains X509 Id cert.

Yes according to my reading of the spec

- How a responder (authz svc) should behave if the data of a subject is supplied in the SubjectConfirmation Element? Is it required to validate the data?

No. The PDP has to authenticate the requestor, and may require the subject to be the requestor, but there is no requirement to authenticate the subject. This should have already been done by the requestor.

4. 6.1.4 Action Elements - I think it would be better to define the string representation more specific. The QName of the operation would be better.

The only requirement is that the requestor (PEP) and responder (PDP) have a common understanding of the action name. I dont agree that a QName would be best, since the URI (the first part of a QName) is already included in the Action element namespace attribute. Thus all we require is the local string name for the operation.

Hope it isn't late,

No, I have made edits to the spec in accordance with the above regards David

Takuya Mori

---- Takuya Mori

-- ***************************************************************** PLEASE NOTE NEW CONTACT DETAILS AS OF 1 JAN 2005 David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NZ 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 *****************************************************************