Hi Brian,
thanks for your response. I have tried to put additional text into version -04
of the draft to address my earlier comments.
The most recent version of the updated document is there:
https://github.com/hannestschofenig/tschofenig-ids/blob/master/oauth-assertions/draft-ietf-oauth-assertions-04.txt
Here is the XML:
https://github.com/hannestschofenig/tschofenig-ids/blob/master/oauth-assertions/draft-ietf-oauth-assertions-04.xml
It took me a little while to make these changes, as you can imagine. I hope I
was able to improve the quality and clarity of the document.
I still have to respond to your second mail about the relaxed usage of the RFC
2119 language. Will do that asap.
Ciao
Hannes
On May 30, 2012, at 11:46 PM, Brian Campbell wrote:
Thanks for the comments Hannes. I've attempted to answer some of your
questions/comments inline below (or at least provide some additional info,
context or explanation).
On Thu, May 24, 2012 at 12:39 PM, Hannes Tschofenig
hannes.tschofe...@gmx.net wrote:
Hi Chuck, Mike, Brian, and Yaron,
I reviewed the document as part of my shepherding role and I believe there is
still room for improvement with the document. I think the document suffers
from the problem that you essentially want to cover every possible use case
in a single document. So, let me start with a high-level mail.
You are covering two quite different usage scenarios that are only related to
each other by the usage of assertions, namely
1. Using Assertions for Client Authentication
2. Using Assertions as Authorization Grants
(Of course these two usages can happen in the same protocol exchange; this
means that you have two assertions in the same message obtained from
different entities with potentially very different properties.)
It is OK to have these two cases in a single document but the introduction
and section 3 need to untangle them and to describe the use cases to the
reader. In fact, the second part of the document (from section 4 onwards)
does a better job in separating the two cases.
Yeah, putting them together has its advantages and disadvantages and causing
confusing between the two cases is one of the biggest downsides. Proposed
text that helps untangle the two usages for the reader/implementer would most
definitely be welcomed.
I was also wondering what use cases you guys find most interested among all
the options I list below? What have you implemented and deployed (I need that
info for the shepherd writeup)? Maybe we should highlight them in the intro.
The primary case I've seen deployed is in an enterprise to SaaS model using
SAML assertions as authorization grants. The enterprise has some kind of STS
that can issue assertions and trust has been established between the STS and
the enterprise's accounts at the SaaS. The client presents some kind local
authentication/authorization to the STS and receives a suitable assertion in
exchange. That exchange is via WS-Trust in the deployments I've seen but
that's far from the only way it can be done. Once the client has the
assertion, the OAuth assertion profile/grant type can be employed to get an
OAuth access token from the AS at the SaaS. Then that token be used to access
the SaaS's protected resources/APIs. The trust established between the
enterprise STS and the SaaS is usually already in place and being used to
facilitate Web SSO traffic.
For the sake of disclosure, my company offers a product that acts in the STS
role described above and one of my co-author's companies is very often the
SaaS. Our product also supports the AS role in that exchange to help enable
organizations to do what the aforementioned SaaS is doing.
In my experience there has been more initial interest in assertions as grants
than for client authentication. But I'll note that OpenID Connect
specifically calls out the JWT assertion profile as one option for client
authentication.
Regarding the security aspects: I assume that the assertions is always
signed. (I guess you make this assumption as well.)
Yes and the draft should say as much. The end of §5.2 explicit says The
Authorization Server MUST validate the assertion's signature... and there
are a number of other places where the text would seem to imply that the
token/assertion is always singed. Do you think it needs to be made more
explicit?
There are a few considerations:
a) Who creates and signs the assertion?
It really depends on the situation. The draft in §5.1 defines it as the
Issuer and attempts to give some ideas about how that might work without
being overly prescriptive or restrictive.
You sometimes use the term Security Token Service (STS) but it is not
introduced in the terminology. Let us assume that this is a third party
entity (and not a role the client can take).
So, we have two cases:
-- Assertions obtained from the STS
