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

[Hal Lockhart <hal.lockhart@entegrity.com>]

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

-----Original Message-----
From: Chopra, Dipak [mailto:dipak.chopra@sap.com]
Sent: Thursday, February 28, 2002 3:16 PM
To: 'security-services-comment@lists.oasis-open.org'
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>