Hi all, I took a look at version -06 of the assertions draft to see whether some of the discussions had been reflected in this recent draft update.
I was hoping that there is a bit more explanation of the use case that motivates the work. Unfortunately, the update does not contain anything along these lines. For example, the use cases could clarify the following aspects: * Why we need these new client authentication mechanisms? This is not necessarily a way in which SAML is used (at least not to my knowledge). If I understood it correctly then the new client authentication mechanism is only used between the client and the authorization server but not with the resource server. Did I correctly read the document? * Then, there is the assertion usage for authorization grants. There, one could argue that the use case is to interwork with existing SAML infrastructure. The same argument does not apply for the JSON based format since there is no transition need (IMHO at least). Ciao Hannes PS: For the shepherd write-up I have to attach information about the implementation and deployment experience. Is there anything I could mention? Has this specification been part of the OpenID Connect interop tests? If so, what specifically had been tested?
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
