[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Comments on Core 12
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC