[OAUTH-WG] OAUTB for Access Token in Implicit Grant
Dear all, We are currently modeling part 1 and part 2 of the OpenID Financial API in the FKS Web Model and have a few questions regarding the OAuth 2.0 Token Binding. In section 3.1. of draft-ietf-oauth-token-binding-06, it is not very clear how an Access Token issued from the Authorization Endpoint is Token Bound. Is this intended to be the same as an AC issued for a web server client? It seems that the user-agent sends both the Provided and Referred Token Bindings to the AS, which means that the AS can bind the Access Token to the Referred Token Binding, which is the Token Binding between the user-agent and the client. However, the Access Token is not used by the user-agent, which means that the client can only send the Token Binding ID used by the user-agent (which essentially is the public key) to the Resource Server. Is this the intended flow of the Token Binding? Because the first paragraph of 3.1 says that the "Token Binding ID of the client's TLS channel to the protected resource is sent with the authorization request as the Referred Token Binding ID", but we assume that the user-agent reveals the TB-ID of its own channel to the client. Best regards, Pedram Hosseyni ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] review of draft-ietf-oauth-mtls-08
Thanks Samuel (even though this doc already went through WGLC!). I'll attempt to address your comments/questions inline below. On Sat, May 12, 2018 at 4:21 PM, Samuel Erdtman wrote: > Hi > > Thanks for a great document. > And thank you too! I have some minor comments. > > in Abstract > “...based on either single certificates...” > Why not write self-signed certificates, to me that is easier to > understand, and is the term that is used later in the document. > The reason why is that it was the term that Justin used in text he proposed for the Abstract that was overall and otherwise much better than the text I'd previously had. But I agree that "self-signed certificates" there would be easier to understand and more inline with the content of the document. I'll make that change in the document source so it'll be in the next draft. > What is the rational behind writing “OAuth protected resources” or just “a > protected resource” instead of resource server? The term resource server is > user later in the document. > At some point many people and documents in this WG started using the protected resource terminology rather than resource server. I don't recall the reason why. Maybe someone on the list here can chime in? As far as I know, they are largely interchangeable. I wrote much of the initial text of this doc using protected resource to try be like the rest of the group. I think Torsten added some text a bit later using resource server. That's the extent of the rational. But I think it's probably okay with both. > > 4.1. Authorization Server > Is it not mandatory for the AS to not do PKI validation of self signed > certificates i.e. the following sentence, “it should configure the TLS > stack in a way”, should be changed to “it must configure the TLS stack in a > way”? > There are different ways one could implement it and this text shouldn't be overly prescriptive. As one example, the TLS layer might do regular PKI validation except for on a specific set of self-signed certificates certs configured for clients using that authn method. > > Finally it might make sense to mention the relation of this document to > RFC7521, RFC7522 and RFC7523. RFC7521 defines a client credentials > framework and the other two are examples of profiles. It also mentions > proof-of-possession. Maybe as an appendix similar to "Relationship to Token > Binding" > RFC7521 defines a framework for using assertions as a client authentication mechanism via the client_assertion_type and client_assertion parameters, which this doc doesn't use. But RFC7521 is not a general client credentials framework. So there's really not much of a relationship to this document. And I wouldn't know what to say in a ""Relationship to ..." section other than that there's not much of a relationship. -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAUTB for Access Token in Implicit Grant
Typically when an access token is issued via the implicit grant directly from the authorization endpoint, it is for a client that is running as script in the user-agent. The AS binds the access token to the referred token binding, which would be the token binding between the user-agent (where the client is) and the protected resource. It does mean that a hybrid style client couldn't pass the access token from its script front-end in the user-agent to its server backed (well, it could pass it but the server side couldn't use it because of the binding). On Mon, May 14, 2018 at 6:46 AM, wrote: > Dear all, > > We are currently modeling part 1 and part 2 of the OpenID Financial API in > the FKS Web Model and have a few questions regarding the OAuth 2.0 Token > Binding. > > In section 3.1. of draft-ietf-oauth-token-binding-06, it is not very > clear how an Access Token issued from the Authorization Endpoint is Token > Bound. Is this intended to be the same as an AC issued for a web server > client? It seems that the user-agent sends both the Provided and Referred > Token Bindings to the AS, which means that the AS can bind the Access Token > to the Referred Token Binding, which is the Token Binding between the > user-agent and the client. > However, the Access Token is not used by the user-agent, which means that > the client can only send the Token Binding ID used by the user-agent (which > essentially is the public key) to the Resource Server. > > Is this the intended flow of the Token Binding? Because the first > paragraph of 3.1 says that the "Token Binding ID of the client's TLS > channel to the protected resource is sent with the authorization request as > the Referred Token Binding ID", but we assume that the user-agent reveals > the TB-ID of its own channel to the client. > > Best regards, > Pedram Hosseyni > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
