Comments on draft-hevroni-oauth-seamless-flow-01:
This draft seems to be about making crypto signatures stateful so you have a
better chance of detecting a cloned key as its state will diverge from the
original.
The link to a seamless OAuth flow seems tangential.
A more common way to make
Hey
My name is Omer, and I want to ask a time to present a draft I'm working on
at IETF 103. This is a new oauth extension, that suppose to allows devices
to authenticate without any user interaction. There are many use cases,
especially in IoT world, where there are devices which need a strong
On 9/17/18 10:22 AM, Thomas Broyer wrote:
On Mon, Sep 17, 2018 at 3:46 PM George Fletcher
mailto:40aol@dmarc.ietf.org>>
wrote:
Hi,
It appears that RFC 6749 and RFC 6750 are inconsistent in regards
to the
HTTP status code that should be returned when a requested scope
Hi Fletcher,
Actually we are not in the same case.
The /token endpoint is a protected ressource in regard to the client
application. The credentials are the client id and, in the case of confidential
clients, the client secret .
The OAuth 2.0 ressource is protected in regard to the user. The
On Mon, Sep 17, 2018 at 3:46 PM George Fletcher wrote:
> Hi,
>
> It appears that RFC 6749 and RFC 6750 are inconsistent in regards to the
> HTTP status code that should be returned when a requested scope is
> "invalid".
>
> For example, if a call is make to the /token endpoint to obtain a new
>
Hi,
It appears that RFC 6749 and RFC 6750 are inconsistent in regards to the
HTTP status code that should be returned when a requested scope is
"invalid".
For example, if a call is make to the /token endpoint to obtain a new
access_token and the scopes requested are outside those issued to
