[security-services] FW: [security-services-comment] SAP Comments OnSAML Core-27 and Bindings-11

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

-----Original Message-----

From: Chopra, Dipak [mailto:]

Sent: Thursday, February 28, 2002 3:16 PM

To: ''

Subject: [security-services-comment] SAP Comments On SAML Core-27 and

Bindings-11

Hi,

I have been following SAML v1 activities for some time. Currently I am

participating in JSR 155 Expert Group. I have reviewed the core-27 and

bindings-11 documents with security developers in SAP.

Please find the collected comments on these two documents.

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.

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"?

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

"AssertionIDReference".

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.          

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.

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.

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.

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

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.

10. Core Document. Line # 863/865. "AttributeNamespace" and "AttributeName'

are optional and in the schema definition, on lines 871/872, these

attributes are required.

11. Core Document. Line # 877. "AttributeValue" is not "Any Number" as

minOccurs=1 (default value).

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.

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? 

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.

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?

16. Core Document. Line # 1109. Does the value

"Error.Reciver.ResourceNotRecognized" belong to "StatusCode" value or is it

the recommended value for the "StatusMessage"?

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

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.

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?

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

"Assertion Integrity".

21. Core Document. Line # 1433. Statement should be "An assertion

..........................., if the super signature applies "to" all the

elements......"

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.

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

"Action Namespace"

24. Bindings & Profiles Doc. Line # 210. I am not sure why there must not be

more than one request element in the SOAP body. You can send multiple

"AssertionIDReference" and "AssertionArtifact" in "Request" but you cant

send multiple "AuthenticationQuery" etc in "Request". What it means is using

one mechanism ("AssertionIDReference", "AssertionArtifact"), you can get

multiple assertions back but using other mechanism "AuthenticationQuery"

etc, you can only get one assertion back. Some explanation would be helpful.

25. Bindings & Profiles Doc. Line # 339. In the example, there is a

"StatusCode" attribute in "Response" element. "StatusCode" is an element in

"Response" element. The example should be modified to reflect this.

26. Bindings & Profiles Doc. Line # 346. In the example, there should be a

closing tag "</samlp:Response>"

27. Bindings & Profiles Doc. Line # 348. None of the two mentioned web

browser SSO profiles, and the SOAP profile seems to make use of the

"AssertionSpecifier" element from the Core Document. Assertions are either

fully contained in the protocol messages or, in the case of the

Browser/Artifact profile, the SAML artifact is used. Some explanatory text

why the element "AssertionSpecifier" is not used here would be helpful.

28. Bindings & Profiles Doc. Line # 467. When source site is creating the

multiple artifacts and relying party gets those artifacts, how does relying

party find out which artifact is meant for authentication statement or

attribute statement? I am not sure if we use "TypeCode" for this. There is

no explanation for this field. Why "0x0001" is mandatory to implement and

what does it signify? Some explanation would be useful.

29. Bindings & Profiles Doc. Line # 535. Whereas the SAML artifact type is

just "String" in the Core Document, the Bindings & Profiles Document now

seems to "overspecify" the artifact format. This "overspecification" results

in additional overhead for negotiating and exchanging distinct SourceID

values and maintenance of the SourceID to URL mappings at each destination

site. Is the URL size problem so severe that these consequences cannot be

avoided? Couldn't it be another option to use an "AssertionSpecifier"

element with an assertionID as an SAML artifact?

30. Bindings & Profiles Doc. If the assertion is created at the time of

artifact creation and the request for this assertion comes after the

assertion has expired, will the source site return the expired assertion or

an error response or a successful response with no assertion?            

Regards,

Dipak Chopra

Technology Architecture Group, SAP

----------------------------------------------------------------

To subscribe or unsubscribe from this elist use the subscription

manager: <http://lists.oasis-open.org/ob/adm.pl>