Hi Brian, Hi all,
I read through the SAML Bearer draft and here are a few comments:
(actually some of the comments that I made yesterday regarding
draft-ietf-oauth-jwt-bearer-06)
Section 3:
Item #1: You wrote: "Issuer
values SHOULD be compared using the Simple String Comparison
method defined in Section 6.2.1 of RFC 3986 [RFC3986], unless
otherwise specified by the application."
I would put a MUST here. You can also use the text I proposed for
draft-ietf-oauth-jwt-bearer-06, which is text I copied from the TLS
specification.
Also the comment regarding the comparison operation I made in
draft-ietf-oauth-jwt-bearer-06 is applicable here.
Item #2: You wrote:
"
Section 2.5.1.4 of Assertions and Protocols for the OASIS
Security Assertion Markup Language [OASIS.saml-core-2.0-os]
defines the <AudienceRestriction> and <Audience> elements and,
in addition to the URI references discussed there, the token
endpoint URL of the authorization server MAY be used as a URI
that identifies the authorization server as an intended
audience. Assertions that do not identify the Authorization
Server as an intended audience MUST be rejected.
"
The 'MAY' is extremely weak here. If you make it a MUST that there has
to be the endpoint URL of the authorization server in there then that
would provide so much more interoperability. As a reader I wouldn't know
what other options I have and systems that provision necessary databases
/ tables to ensure that the comparison takes place will also struggle.
Then, there is again this SHOULD regarding the comparison operation, see
"
Audience
values SHOULD be compared using the Simple String Comparison
method defined in Section 6.2.1 of RFC 3986 [RFC3986], unless
otherwise specified by the application.
"
I would replace it with a MUST, as I argued in
draft-ietf-oauth-jwt-bearer-06.
Item #3: As in the draft-ietf-oauth-jwt-bearer-06 this part is extremely
fluffy, except for the case where it talks about the client-id. What
exactly do I put into the field in the case of an authorization grant?
Item #5: You write:
"
The <Subject> element MUST contain at least one
<SubjectConfirmation> element that allows the authorization
server to confirm it as a Bearer Assertion.
"
What do you mean that the AS confirms that it is a bearer assertion? I
think what you rather want to say is that the AS indicates that it is a
bearer assertion.
Item #7+8: T I think you should combine the two items since they relate
to the same issue, namely when to include the <AuthnStatement> element.
There are two questions:
Q1: Has the subject been authenticated?
If 'no', then the <AuthnStatement> cannot be populated.
If 'yes', then
Q2: Has the subject requested to be anonymous?
If 'no', then the <AuthnStatement> element is populated
with the subject's identity.
If 'yes', then the <AuthnStatement> MUST NOT be populated.
(or populated with a field that indicates that the subject
is anonymous; I don't know SAML enough to tell what the
right approach here is).
Then you write:
"
The presenter SHOULD
be identified in the <NameID> or similar element in the
<SubjectConfirmation> element, or by other available means like
SAML V2.0 Condition for Delegation Restriction
[OASIS.saml-deleg-cs].
"
Who is the presenter? Is the presenter the subject?
Item #10: You write:
"
10. The Assertion MUST be digitally signed or have a keyed message
digest applied by the issuer. The authorization server MUST
reject assertions with an invalid signature or keyed message
digest.
"
To my knowledge SAML assertions only support digitial signatures and no
keyed message digests.
Security Consideration section:
I believe the section needs to say two things into addition to the
reference to the other specifications, which are already included in the
security consideration section:
a) The specification does not mandate replay protection for the SAML
assertion usage for neither the authorization grant nor for the client
authentication. It is an optional feature.
b) There is actually no authentication happening when these SAML
assertions are used for client authentication and for the authorization
grant (in the classical definition of authentication). This may be
surprising to some why typically assume that the client would have to
demonstrate proof of possession of a secret, which isn't the case here.
It would have been possible to provide more enhanced funtionality (and
SAML supports this as well) but it is not provided in the specification.
Maybe a future specification will provide that functionalility.
I think it is worth pointing out.
Ciao
Hannes
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
