RE: Comments on Core 12

Title: RE: Comments on Core 12

Prateek - Thank you for your response.  You have outstanding questions on comments numbered: 3, 8, 10, 12, 15.  I have deleted the others, and respond to these below.  Best regards.  Tim.

3 (major). Section 1.2.  We should allow an AssertionSpecifier to be

verifiably-linked to a specific assertion, i.e. it may be a digest of the

assertion.  This is hinted at in 1.1.1.1.  However, for the linkage to be

verifiable, we need identifiers for the specifier type and the digest

algorithm.

 

[Prateek Mishra] I understand that generally speaking including a hash

provides for a tighter binding of a reference to a specific assertion, e.g.

It's not just the assertion with ID 1232, it also the assertion with hash 

263^21&^*%ba.  This appears to me orthogonal to the requirement for digital 

signing of assertions to ensure integrity. So I guess my question is: if digital

signing is used, is there still a role for a hash (as part of an assertion

specifier)?   Maybe the case where I have a signed assertion referencing 

unsigned assertions is the case of interest here. By including the hash in 

the signed assertion, we are able to bind unambiguously to the unsigned assertions.

[Tim Moses] I think there is a role for a cryptographically-strong assertion reference.  If the PEP and PDP operate "at arms length", then the "advice" element of the authorization decision assertion provided by the PDP to the PEP should contain the assertions upon which it based its decision, or (in the case that those assertions were provided by the PEP) a cryptographically-strong reference to those assertions.  This is important, whether or not the assertions were signed.

8 (major). Section 1.5.1.1.  We should allow the "object" element to contain

a digest of a data object, or the object itself.

[Prateek Mishra]  The <Object> element has been deemed outside the f2f#3

discussion and will vanish

in the next iteration of the spec. However, its contents will remain:

namespace, actions(1 or more) and resource URI.

While it is tempting to connect a resource URI with a hash, I would argue

that this is strongly restrictive and will not

scale to a broad class of policy engines. Resource URI's may refer to many

different kinds of objects, even

objects that do not have any digital representation. Examples include: a

method of an EJB, name of a natural

resource, financial instrument name etc. Second, the policy engine may be

based on some kind of deductive

system:

    only engineers can access the contents of /design/ directory

    only premium traders can sell derivatives

and generates its responses based on rules of this type (e.g., action=SELL

resource=FIVE_YEAR_TREASURY)

[Tim Moses] It was not my intention that the digest be the only way of identifying an object in an assertion.  I agree with all your counter-examples.  There will be occasions when an Authorization Query will include the actual business document, and the corresponding authorization decision assertion will contain the reference to that document.

10 (major). Section 1.7.2.  "Audience" should be able to specify a "use", as

well as a "community". 

[Prateek Mishra] Could you explain further? Why isn't audience enough?

Notice that an assertion can be directed

to many different audiences. You seem to be implying that we need to

"decompose" audience further into sub-parts. 

[Tim Moses] Perhaps, this is mislabeled.  It should be a "minor" comment.  I merely request that the text make it clear that the approved uses of the assertion may be constrained.  There is no need, in my mind, for a finer structure to the <Audience> element.

12 (major). Section 2.3.1.  I believe the requester needs an opportunity to

specify the authentication protocols that it supports and the space in which

the subject's name should be expressed.

[Prateek Mishra]  Just to clarify my understanding of this comment: you are

suggesting that there be a more expressive query language for

AuthenticationQuery. Further, that it be possible to query against the

<Authenticator> element or <subject> element.

I can see the point of such an extension. But I have a question for you.

Generally speaking, we would expect only a few AuthenticationAssertions

for a subject (order of magniture 10^2 or fewer). Can't the requestor sort

thru the returned assertions and choose the relevant ones? This avoids

the tangled issue of developing a richer query language. Or are there

concerns other than efficiency behind your suggestion?

[Tim Moses] On the first point (specifying the authentication protocol) my concern is solely for efficiency.  If the relying party is only capable of authenticating with a bearer token, then there is little point in returning assertions in which the <Authenticator> element contains a password digest, or a public key.  As currently specified, the relying party can constrain how the Authentication Authority authenticated the subject, but it may wish to use a different scheme itself, and needs an authentication assertion that is suitable for its chosen scheme.

[Tim Moses] On the second point, an Authentication Authority, acting as a third-party service provider may know the same subject by many different names (their bank account number, their Home Depot customer number, etc.).  For privacy/identity-theft reasons, it won't be acceptable to return all such names and allow the relying party to sort through them and find the appropriate one.  One could argue that the relying party is only "qualified" to see certain names and only authentication assertions containing those names should be returned.  I think I would be happy with this answer.  But, an explanation in the text would be helpful (would such an explanation belong in "security consideration"?).

15 (major). Section 2.5.  The PEP should be able to supply additional

information, possibly in the form of "environmental assertions" upon which

the PDP may base its decision.

 

[Prateek Mishra] Are you suggesting that an (optional) <Advice> element be

added both to the SAMLQueryType and SAMLResponseType? This

would provide a standard element for pointing to "additional" information

relevant to the query and the response. That would certainly make

sense to me. 

[Tim Moses] This solution would be fine with me.