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.Tschofenig@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
> 
>  -- Assertions self-generated by the client
> 
> Needless to say that the security properties are different between the two. In the second case the party receiving the assertion cannot trust the content in the assertion since it had been minted by the client, an untrusted party.
> 
> The client is not necessarily untrusted.  In the case where the client is the issuer, it really needs to be trusted for it to work. That probably makes the most sense when using assertions as client authentication where the client sends an assertion that demonstrates possession of a (symmetric or asymmetric) secret. But it really depends on the situation so that's just one possibility. 
>  
> 
> Also note that the protocol for obtaining the assertion from the STS may not have been standardized, which consequently does not necessarily increase interoperability when deploying such a solution. Any story for this? How did you handle this in your implementations & deployments?
> 
> Interoperability between the client and the AS is the primary goal of this spec (and the SAML/JWT incarnations of it). That may impose some requirements on the STS with respect to the actual content and format of the assertion. However, the rest of the client <-> STS exchange should have no bearing on interop (other than between those two parties but that is out of scope here).  
> 
> For what it's worth, as I mentioned earlier, my product offers WS-Trust as a means for obtaining the assertion. It's not the only way and it's arguably not ideal. But it is a standard for token exchange and it was something we already had a lot of infrastructure in place to support in our product.
>  
> 
> Let us focus on the cases where the assertion is obtained from an STS. Then, the assertion is signed by the STS (hopefully) and if the client presents it then it can do that in two ways:
> 
>  -- Conveying the assertion as a Bearer Assertion (i.e., possession is the security) and hopefully the exchange runs over TLS. Replay protection can be provided via the parameters in the assertion assuming the client has a capability to obtain assertions on the fly using some protocol to essentially present a refresh assertion with (almost) every exchange since otherwise the provided security really suffers.
> 
> FWIW, this whole document more or less assumes that the assertion will be a bearer assertion. I don't think there's anything necessarily preventing a holder of key profile from being written on top of it but the SAML/JWT realizations of this draft are explicitly and intentionally limited in scope to the bearer case.
> 
> And yes, this exchange must run over TLS (OAuth core at http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-3.2 mandates it for the token endpoint which then is inherited by this spec).
>  
> 
>  -- Using the assertion together with a holder-of-the-key concept. In this case the assertion would be signed by the STS and then the client in addition needs to show possession of a secret (which is bound to the token). This secret (either a shared key or a public/private key pair had been obtained somehow).
> 
> Again, I think a HoK assertion/confirmation could be profiled from this draft but it hasn't been done yet and I really haven't heard anyone asking for it.
>  
> 
> Furthermore, the document at various places talks about the great security properties and I believe that this is a bit misleading. The great security properties are only there when you either use
> 
>  * a STS obtained assertion with a holder-of-a-key assertion, or
> 
>  * let the client sign the assertion (in which case the assertion is quite degenerated*).
> 
> I believe those security benefits are really only particularly relevant for [H]MAC'd assertion being used for client authentication as an alternative to sending the client secret directly via HTTP Basic or as a parameter. This should probably be made more clear so as not to be misleading.
> 
> 
> It may also be worth noting that not all assertions can be signed with symmetric as well as asymmetric credentials. A SAML assertion, for example, can only be signed with an asymmetric credential (at last to my knowledge).
> 
> 
> 
> That is standard practice with SAML and the only thing I've ever seen implemented/deployed but there is nothing that actually mandates asymmetric signatures in SAML.
> 
>  
> Ciao
> Hannes
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>