Some comment and questions on the latest drafts.  My comments use the below numbers to reference each spec

 

[1] "Use of XACML Request Context to Obtain an Authorisation Decision, 31 Oct 2007"

[2] "Use of WS-TRUST and SAML to access a CVS, 31 Oct 2007"

 

Comments on [1]:

1)      The definition of a credential in section 4.2.2 and in [2] are different. I prefer this definition.  In the credential table, you could use “wsse:Kerberosv5ST” as the Kerb token value type per the WS-Security Kerberos profile, though perhaps you don’t want to drag in yet another namespace. I believe you’ll have to define an identifier for proxy certs and SAML assertions.

 

2)      The obligation encoding seems okay. I don’t have a good feel for whether the defined obligation IDs are the right ones to standardize and require all implementers to handle. It would be good to hear from others who have been building XACML-based solutions.

 

3)      Should this spec define an interop security profile for authentication, integrity, and confidentiality of messages between the PEP and PDP? The SAML standard defines some options but I don’t believe anything is mandatory. Seems like it should at least be discussed in the security considerations section.

 

Comments on [2]:

1)      The WS-Trust spec referenced is obsolete. I suggest you reference the  OASIS standard WS-Trust 1.3, 19 March 2007. http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html. I don’t believe the change has a significant impact on the design in this spec, though it may need a few minor tweaks.

 

2)      In section 3 it says “The PEP may provide any arbitrary set of credentials, e.g. member of university X, member of grid project Y, registered doctor, certified engineer etc. issued by any arbitrary set of attribute authorities (AAs) or credential issuers; as well as any arbitrary set of references (meta-information) to credential issuing services.”

 

I would argue that you are describing ‘claims’ asserted by some set of issuing authorities, not credential types.  In any event, this seems to contradict spec [1] which says in 4.2.2 “If a bag of unvalidated credentials are passed by the PEP to the PDP, these credentials may be in a variety of formats e.g. X.509 public key certificate, X.509 attribute certificate, X.509 proxy certificate, VOMS attribute certificate embedded in a proxy certificate, Kerberos Ticket, Shibboleth attribute, proprietary credentials etc.”

 

If the definition in this spec is what was intended, then it seems to imply the PEP or PDP would be responsible for validating signatures/integrity of input security tokens (credentials as defined in [1]); decoding the token and re-encoding the information into a set of SAML claims and associated issuing authority(s). This spec makes sense if I make this interpretation, I’m just uncertain if that’s what was intended. Perhaps some clarifying text could be added?

 

3)      In 3.1 “the CVS returns a set of valid attributes to the PEP, that are in the correct format for passing to the PDP”.  I would suggest you change this to “… for passing to the XACML PDP” and note in the introduction that this spec assumes an authZ environment with an XACML PDP.  That would make it consistent with the statement in 3.2 that “..the CVS described in this document is a source of attribute values that are ready to be passed to an XACML conformant PDP.”

 

4)      From section 4 (and 5 & 6), definition of supported SAML assertions, #4 says “The NameID option MUST be used, and the Format SHOULD be X.509 subject name.”. From this I take it the intent is to restrict this profile to the use of authentication infrastructures which identify principals using X.509 DNs? That should probably be clarified in the introductory material.  X.509-based grid authN is certainly the most common case today, but is problematic if using non-X.509 tokens such as Kerberos.  Related to ‘2’ above, the description here makes sense if one assumes the PEP or PDP re-encode security token information as SAML assertions.  I’m unclear on the intended processing model if one is allowed to pass unvalidated security tokens. It seems that the requestor would need to parse the tokens to fill in the mandatory issuer information in the request, which would adds complexity to the PEP or PDP.

 

5)      Should this spec define an interop security profile for authentication, integrity, and confidentiality when using the defined WS-Trust profile? Seems like it should at least be discussed in the security considerations section.

 

Regards,

Blair