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: [security-services] FW: [security-services-comment] SAP Comme ntsOn SAML Core-27 and Bindings-11


Title: RE: [security-services] FW: [security-services-comment] SAP Comments On SAML Core-27 and Bindings-11

Preliminary assessment of SAP comments.

Items 1-12 & 14, 15 reflect discussion on the 3/5 focus group call.

Items 13 & 16-23 reflect my analysis.

Items 23-30 are discussed by Prateek in a separate message.
 
> 1. Core Document. Line # 331. Why "Indeterminate"
> DecisionType is required?
> "Permit" and "Deny" are enough. When making an authorization decision
> statement, what extra information PDP (Policy Decision Point)
> is providing
> by setting "DecisionType" to "Indeterminate"? Some
> explanation would be
> useful why "Indeterminate" is required.

Indeterminate could be used in one or both of the following cases: the PDP has no policy covering this request and more information is required to make the decision. These case could also be covered by error responses. The notion behind having the Indeterminate result is that since assertions may be issued without using the request/response protocol, there may be situations in which it is useful to issue such an assertion. Unfortunately, no plausable example has been offered. The question goes to the heart of the domain model. Does a PEP rely on one and only one PDP for all its decisions? Clearly explanitory text is required here. The XACML TC has also been working in this area and will comment in this issue.

 
> 2. Core Document. Line # 350. Elements "AssertionIDReference" and
> "Assertion" do not the expressive enough names. "AssertionID"
> is already a
> reference to the underlying assertion. Why can't we have
> something simpler
> like "AssertionByRef" and "AssertionByVal"?

The name Assertion can not change, because it is a reference to the actual Assertion element. Given this, the value of changing AssertionIDReference is questionable.

> 3. Core Document. Line # 366. Element "AssertionID" should be
> "AssertionIDReference".

This is an error and will be corrected.

> 4. Core Document. Line # 371. On lines Line 231 and 1074,
> there is a usage
> of term "authentication assertion". Then "Assertion" element has
> "AuthenticationStatement" as a child element. I would say this causes
> confusion.  I think there is nothing like authentication
> assertion at least
> if you look at the schema. I would suggest that terms like
> "authentication
> assertion", "attribute assertion" should be removed.

This is an error. The introduction of three statement types rather than three assertion type is relatively recent. As a result all the specifications need to be corrected in multiple places.

         
> 5. Core Document. Line # 493. What is the difference and relationship
> between "Audience" and "Target"? Both are "anyURI" type. Both
> talk about
> "party". There should be some explanation about the
> difference between these
> two elements. I think the difference lies in the usage of these two
> elements.

Target has now been moved to response message. Additional explanitory text is needed to make the distinction clearer.

> 6. Core Document. Line # 541. "saml:Target" has "minOccurs"
> as 1. It is
> inconsistent with the rest of document for handling the
> default values. In
> the rest of document, if "minOccurs" and "maxOccurs" are
> supposed to have
> default values, it is not mentioned in the schema.

This is an error however Target is being moved to the response, so it no longer applies.

> 7. Core Document. Line # 639. Inconsistency in the attribute schema
> definition. "SecurityDomain" attribute definition, which is
> "optional", does
> not have the attribute "use" as "optional" whereas on line
> #714, "IPAddress"
> attribute definition has "use" as "optional". I think it should be
> consistent through out the document.

This is an error and will be corrected. Note NameIdentifier is being reworked.

> 8. Core Document. Line # 678. Element "AuthenticationLocality" seems
> confusing. "AuthenticatedPrincipalLocality" (or something
> like this) makes
> more sense. "AuthenticationLocality" seems to provide the
> information about
> where the authentication was done especially when you look at
> this attribute
> at the same place, where you see attributes like
> "AuthenticationMethod" and
> "AuthenticationInstant".

It was agreed to change this to SubjectLocality.

> 9. Core Document. Line # 829. With the current "Action"
> schema, we can't
> authorize a subject for a range. In other words, PDP can't
> set two related
> Action items. A specific implementation might interpret two
> actions as if
> they are related. For example, you need to authorize a
> subject for his
> "SpendingLimit" from $1000 to $2000. You can't do that? In
> SAP applications
> (as everywhere else!), supporting authorizations in some ranges,
> responsibilities is often required.

If you want to say a subject may spend up to a certain amount or a range of amounts, you should use an Attribute Statement. (although saying you can spend between $1000 and $2000, but not less than $1000 seems odd.) If you want an Authorization policy decision about a particular action, you should specify the exact action amount in question, e.g. $1234.56.

> 10. Core Document. Line # 863/865. "AttributeNamespace" and
> "AttributeName'
> are optional and in the schema definition, on lines 871/872, these
> attributes are required.

This is an error. They should be the same. No one on the 3/5 call was sure which was correct.

> 11. Core Document. Line # 877. "AttributeValue" is not "Any
> Number" as
> minOccurs=1 (default value).

This is an error. However, schema tools don't like "anyType" when imported into another schema. This needs to be investigated.

 
> 12. Issue DS-4-11. Core Document. Line # 969. Why can't we take
> "RespondWith" zero statement resulting into a response with
> "StatusCode" as
> "Success"? This can be useful where client wants to test SAML
> Processor
> (without requesting any assertion information) if it accepts
> SAML requests
> or not.

This is a clever trick, but there are other ways to accomplish the same thing. The sense of the TC seems to be to prohibit zero statements.

> 13. Core Document. Line # 1020. When relying party gets
> multiple artifacts,
> it needs to get the corresponding assertions. It sends a
> single SAML request
> with all the artifacts, lets say there are errors in some assertions
> retrieval and some are retrieved correctly at source site.
> What kind of
> respond is returned by source site?

This behavior should be specified as a part of a profile. Currently only the Web Broswer/Artifact Profile uses this form of query. Bindings-11 lines 513-514 specifies that an error must be returned in this case. However, more detail should be specified to insure interoperability.

> 14. Core Document. Line # 1078. What is the difference between
> "ConfirmationMethod" element in "AuthenticationQuery" and
> "AuthenticationMethod" attribute in
> "AuthenticationStatement"? There should
> be some explanation. What is the difference between
> "ConfirmationMethod" in
> "AuthenticationQuery" and "ConfirmationMethod" in
> "SubjectConfirmation"?
> Some explicit differences or similarities would be helpful.

Text has been previously proposed to explain this distinction. It will be added to the core specifiction.

> 15. Core Document. Line # 1081. It says that there can be multiple
> assertions with multiple authentication statements for a given
> AuthenticationQuery. I think the responder should return a
> single assertion
> element (as defined in section 2.3.3) with multiple authentication
> statements. 
> Then it says that the subject element of returned assertions MUST be
> identical to the subject element of the query. First of all, I think
> statement should say that "subject element of authentication
> statements".
> Second, if the subject elements are identical in all the returned
> authentication statements, and then "AuthenticationInstant",
> "AuthenticationLocality" and "AuthorityBinding" are also
> identical, it means
> that all the authentication statements are identical except for
> "AuthenticationMethod". So why do we need multiple authentication
> statements? Am I missing something here?

1. In general, several statements in one assertion have the same semantics as if the statements appeared in distinct assertions.

2. The wording change from assertion to statement is correct and will be made.

3. It is perfectly possible for a subject to authenticate several times using the same or different methods. Each authentication statement reports a distinct authentication act.

> 16. Core Document. Line # 1109. Does the value
> "Error.Reciver.ResourceNotRecognized" belong to "StatusCode"
> value or is it
> the recommended value for the "StatusMessage"?

This is an error. The Status element has evolved recently. This text needs to be aligned with section 3.4.3.

> 17. Issue DS-12-06. Core Document. Line # 1112. In
> "AttributeQuery", if no
> attribute is specified, the list of desired attributes is
> implementation
> specific. It makes more sense to return all the attributes.
> This can be very
> useful in the case where a subeject might have large number of
> attributes
> (say 100) and you need to get all the attributes. With the current
> mechanism, you need to write all the attributes, which is a
> tedious job.

There is an open issue (DS-12-06) around this. The TC clearly wants a way to say "give me all the attributes policy allows", but we have not agreed whether this should be done by specifying none or by means of a keyword, such as "ALL".

> 18. Core Document. Line # 1244/1246. "Receiver" and "Sender" seem
> inappropriate. These are the values for "StatusCode" element,
> which is a
> part of "Response". Please notice that there are two
> messages, "Request" and
> "Response". Something like "ProcessorError" and
> "RequesterError" makes more
> sense, which explicitly shows an error and its location.

All the documents are being changed to use the terminology requester/responder.

> 19. Core Document. Line # 1312. Why this section is not valid for
> AuthrizationQuery? How do you match a subject in the case of
> authorization
> decision query?

Authentication and Attribute statements are inputs to an Authorization Policy decision. An Authorization decision statement reports the result. Therefore, the same strong matching of subject confirmation method is not required. However, the specification could be clearer.

> 20. Core Document. Line # 1381. "Message Integrity" should be
> changed to
> "Assertion Integrity".

This is an error and will be corrected.

> 21. Core Document. Line # 1433. Statement should be "An assertion
> ..........................., if the super signature applies
> "to" all the
> elements......"

This is an error and will be corrected.

> 22. Core Document. Line # 1438.  "SAML message" should be
> changed to "SAML
> structure" (or something like this) as SAML assertion is not an SAML
> message.

This is an error. We need to determine the right term to use here.

> 23. Core Document. Line # 1622. "ActionNamespace" should be
> changed to
> "Action Namespace"

This is an error and will be corrected.


Hal



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


Powered by eList eXpress LLC