OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: 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  However, for the linkage to be
verifiable, we need identifiers for the specifier type and the digest
[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  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

    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

[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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC