RE: Comments on Core 12

["Mishra, Prateek" <pmishra@netegrity.com>]

Tim,
 
some followup on your comments.

-----Original Message-----
From: Tim Moses [mailto:tim.moses@entrust.com]
Sent: Friday, August 03, 2001 2:54 PM
To: 'OASIS Security Services group'
Subject: Comments on Core 12



Colleagues - I have the following observations/comments/questions on Core
12.  Best regards.  Tim. 

1 (major). Section 1.  Definition of Authentication assertion.  This
definition is a bit limiting.  How about ... " ... an assertion by the
issuer that the subject was authenticated by a particular means at a
particular time, and including information by which a relying party can
confirm that an entity claiming to be the subject of the assertion is,
indeed, the subject.  The assertion may (but does not have to) include a
name for the subject.  The assertion may (but does not have to) contain
authentication information by which the relying party can authenticate the
subject.  In the case of a bearer token, the authentication information may
be missing.  In which case, the relying party must deduce from the
environment that the presenter of the assertion is the subject."
 
[Prateek Mishra] Sounds good to me. 

2 (minor). Section 1.  Attribute assertion.  Is there a reason for saying
"is associated with", instead of "possesses"?  "Possesses" seems more
straight-forward.
 
[Prateek Mishra] works for me.  

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.

4 (major). Section 1.3.2.1.  We should allow the authenticator to be a
digest of a data object (e.g. XML document), then we can attach assertions
to objects.
[Prateek Mishra]  I assume we would need to call out specific type and
digest algorithms? It would be useful to make 
a first-cut at a list here. (PKCS#7, MIME-CMS, <dsig:reference>, others?)

5 (minor). Section 1.3.2.1.  Can we be more specific about the use of
"AuthData"? 
[Prateek Mishra] The only really good example I have seen is a password hash
(e.g., UNIX passwd). Is a Kerberos ticket a second example?  
Presumably, specific linkages between <Protocol>, <KeyInfo> and <AuthData>
need to be called out in Section 4.1. 

6 (minor). Section 1.4.1.  The "AuthenticationCode" and "Audience" elements,
together, serve the same purpose that the "certificatePolicies" extension of
X.509 serves.  Can be learn anything from the experience with X.509?

7 (minor). Section 1.4.1.  Why did we choose the term
"AuthenticationLocale"?  Aren't we actually identifying the authentication
authority?  So, isn't that a more appropriate term?
[Prateek Mishra] No, we are not identifying the authentication authority
here. We are capturing the "dns" address of the entity being authenticated
(authenticatee?). So
maybe the correct element name is <AuthenticateeLocale> or <EntityLocale>?

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)

9 (minor). Section 1.6.1.1.  Does the syntax express the relationship that
there can be one or more attributes, each with zero or more values?
[Prateek Mishra] The AttributeType and AttributeValueType express precisely
these constraints.

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. 

11 (major). Section 2.2.2.  I believe there are circumstances under which
the SAML request must convey "both" an assertionID and a query.  I have an
outstanding action to explain where this need arises.

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?

13 (minor). Section 2.4.  Delete: "The response will be in the form of an
Attribute Assertion", and replace it with "A successful response will be in
the form of one or more Attribute Assertions". 

14 (major). Section 2.4.1.  As currently defined, the
"CompletenessSpecifier" is redundant.  The requester can only ask for the
set of attributes that it is qualified to receive.  So, there is no need to
specify behaviour in the event that there are other attributes that it is
not qualified to receive.
 
[Prateek Mishra] This issue was addressed in the August  7 con-call. Philip
has issued an update:
http://lists.oasis-open.org/archives/security-services/200108/msg00026.html
<http://lists.oasis-open.org/archives/security-services/200108/msg00026.html
> 


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 
Tel: 613.270.3183