Just catching up here - thanks for the comments Hannes. Did you merge these in by yourself?
-cmort On May 24, 2012, at 11:39 AM, Hannes Tschofenig 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. 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. > > Regarding the security aspects: I assume that the assertions is always > signed. (I guess you make this assumption as well.) > > There are a few considerations: > > a) Who creates and signs the assertion? > > 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. > > 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? > > 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. > > -- 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). > > 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*). > > 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). > > Ciao > Hannes > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
