It would be helpful if the draft identified the various cases that are
intended to be supported. For example,
in draft-ietf-oauth-assertions-10, there is a helpful distinction made
between "Client acting on behalf of a user" vs.
"Client Action on behalf of an anonymous user" (vs. even more advanced
use-cases). Otherwise, folks
have a hard time figuring out the pieces they need to implement and the
required behavior.
It feels like Section 3 speaks to all of these cases simultaneously. I
think this is confusing and
our developers have raised some questions about it.
BTW, it would also help if the rules in Section 3 were numbered.
1) For the case where we have "Client acting on behalf of user" - this
case seems to be where we
have something like a SAML SSO assertion - complete with Subject
identifying the
"authorized accessor or delegate". The Client offers this bearer
instrument as an access grant and the Authorization
server understands that its "acting on behalf a user".
a) As the SAML assertion is a bearer instrument and can be stolen, the
authorization server should insist on client credentials being present.
In other words, the client should be confidential. What is the value in
permitting a public client to participate in this exchange?
b) Further, as part of its processing rules, once the client has been
authenticated
the authorization server should determine whether the particular client
has the right to present the SAML bearer assertion.
c) What is the value of including an AuthNStatement? Specifically, what
does the Authorization server understand by its
presence or absence? What is the guidance to deployers? Should they
require end-user authentication to have taken place?
2) Bullet 5 (counting from the bottom of Section 3) references a more
advanced use case based on a SAML delegation
model. Is this the ONLY case where AuthNStatement's are allowed to be
omitted? If so, that should be stated clearly.
I think this bullet refers to an advanced use-case and should be moved
to an independent section.
I think by "the presenter act autonomously on behalf of the subject" you
mean something like "Client acts on Behalf of Anonymous Users".
as identified in draft-ietf-oauth-assertions-10.
I also found the sentence "The presented SHOULD be identified in the
<NameID> or similar element,.." problematic. Its pretty open ended
and it seems to me it will be difficult to have an interoperable
implementation based on this text.
Finally, what are the additional processing rules that the authorization
server needs to implement when processing this class of SAML assertions?
3) Has there been any interoperability testing of this profile? This is
an activity we would be interested in.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
