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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
