Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-06.txt

[Manger, James]

Syntax glitches in draft-ietf-oauth-pop-key-distribution-06:

1. "exp" and "nbf" values should be numbers, not strings, so must not have 
quotes [Section 4.2.2. "Client-to-AS Response"]

2. h'11' and b64'...' appear in the JSON examples, but should be "..." strings 
[Section 4.2.2. "Client-to-AS Response", members "kid", "x", "y"]

3. "iss" should be an https URI, such as "https://server.example.com;, not 
"xas.example.com" [Section 4.2.2. "Client-to-AS Response"]. "aud" should 
probably be https://... as well, not http://

--
James Manger

-Original Message-
From: OAuth  On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, 12 March 2019 12:37 AM
To: i-d-annou...@ietf.org
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-06.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

Title   : OAuth 2.0 Proof-of-Possession: Authorization Server 
to Client Key Distribution
Authors : John Bradley
  Phil Hunt
  Michael B. Jones
  Hannes Tschofenig
  Mihaly Meszaros
Filename: draft-ietf-oauth-pop-key-distribution-06.txt
Pages   : 17
Date: 2019-03-11

Abstract:
   RFC 6750 specified the bearer token concept for securing access to
   protected resources.  Bearer tokens need to be protected in transit
   as well as at rest.  When a client requests access to a protected
   resource it hands-over the bearer token to the resource server.

   The OAuth 2.0 Proof-of-Possession security concept extends bearer
   token security and requires the client to demonstrate possession of a
   key when accessing a protected resource.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-06
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-pop-key-distribution-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-key-distribution-06


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] OAuth Device Flow spec renamed to “OAuth 2.0 Device Authorization Grant”

[Mike Jones]

I made a blog post about the renaming of the device spec and last-minute 
clarifications applied at http://self-issued.info/?p=1959 and 
@selfissued.  Thanks again to William for doing 
the heavy lifting!

Hopefully this is the version that gets sent to the RFC Editor…

  -- Mike

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

[Vittorio Bertocci]

Hi all,
during today's office hours call I pointed out that oauth-mtls-13's abstract
only mentions access token, although the spec does provide (some) guidance
on  refresh token binding as well.
Although in the end implementers would do the right thing, given that they
have to read the spec in its entirety, having a mention of refresh tokens
in the abstract as well would make it easier for superficial readers to
learn that the spec does address RTs as well. Refresh tokens leakage is one
of the top concerns of the customers I deal with, and those people rarely
read specs from cover to cover: having language in the abstract explicitly
calling out RTs might make some conversations easier.

This is admittedly very minor, but the fix would also be pretty easy,
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-15.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

Title   : OAuth 2.0 Device Authorization Grant
Authors : William Denniss
  John Bradley
  Michael B. Jones
  Hannes Tschofenig
Filename: draft-ietf-oauth-device-flow-15.txt
Pages   : 23
Date: 2019-03-11

Abstract:
   The OAuth 2.0 Device Authorization Grant is designed for internet-
   connected devices that either lack a browser to perform a user-agent
   based authorization, or are input-constrained to the extent that
   requiring the user to input text in order to authenticate during the
   authorization flow is impractical.  It enables OAuth clients on such
   devices (like smart TVs, media consoles, digital picture frames, and
   printers) to obtain user authorization to access protected resources
   without using an on-device user-agent.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-15
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-device-flow-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-15


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Device flow error response

[Emond Papegaaij]

Hi Filip,

Yes, this was exactly what I was thinking about. Good to know I'm
working in the right direction. I must say that the spec reads really
well and is fairly straightforward to implement.

Best regards,
Emond Papegaaij
Topicus KeyHub

On Mon, Mar 11, 2019 at 6:29 PM Filip Skokan  wrote:
>
> Hi Emond,
>
> the way i approached implementation of device flow into an OIDC server was to 
> allow all already registered and handled parameters excluding the ones [1] 
> that really don't make sense for the flow at the device authorization 
> endpoint.
>
> What can be validated at the device authorization endpoint time is, 
> everything else runs as part of the regular authorization pipeline for which 
> i also construct the request based on the params saved together with the 
> device code backend model. Everything else that depends on the actual device 
> where authnz happens is processed as part of the web request following the 
> user code submission. When errors occur that cannot be resolved with user 
> interaction the error is assigned to the device code and returned to the 
> device with the next poll. I did not exclude prompt:none, as the pipeline 
> processing starts after the submission it's possible that no prompt will 
> occur there, but i can see how it may be weird. Yes the result at the token 
> endpoint will include an id token if the scope included `openid` as one would 
> expect, just like it will include a refresh token if `offline_access` is 
> present. `resource` specifically is available as per the resource indicator 
> spec at device authorization 
 as well as token endpoints.
>
> I guess this is very similar to what you're thinking.
>
> I don't think we need to (and can for that matter) enumerate all possible 
> OAuth2.0 extensions in the specification.
>
> [1] web_message_uri, web_message_target, response_type, response_mode, state, 
> redirect_uri
>
> S pozdravem,
> Filip Skokan
>
>
> On Mon, 11 Mar 2019 at 15:02, Emond Papegaaij  
> wrote:
>>
>> Yes, that's how I implemented it as well. I return 'invalid_request'
>> when the client_id is missing entirely.
>>
>> Do you have any thoughts how this specification should work in
>> combination with other specs, such as OIDC? For example, the OIDC
>> Authentication Request specifies several additional parameters, some
>> of which may be applicable for the device flow as well. Can the device
>> flow be used to obtain an ID token? How should parameters like
>> 'max_age', 'id_token_hint' and 'claims' be processed? My plan was to
>> construct a pseudo-authentication/authorization request using the
>> parameters specified at the device authorization endpoint and apply
>> these parameters during the user interaction. Some parameters, such as
>> 'prompt=3Dnone', do not make much sense though.
>>
>> I think it may be a good idea to describe how this spec is supposed to
>> interoperate with other specifications, especially those that extend
>> the Authorization Endpoint. This definition can never be complete, as
>> new specs will be defined after this one, but it can at least try to
>> describe the general rules that apply.
>>
>> PS. Other specifications also define additional parameters that may be
>> useful, such as: 'resource' from Resource Indicators for OAuth 2.0 and
>> 'include_granted_scopes' from OAuth 2.0 Incremental Authorization.
>>
>> Best regards,
>> Emond Papegaaij
>> Topicus KeyHub
>>
>> On Fri, Mar 8, 2019 at 10:24 PM Brian Campbell
>>  wrote:
>> >
>> > While probably not terribly important from an interoperability 
>> > perspective, I agree that does seem like an omission.
>> >
>> > I took a quick look at our implementation and bad requests to the device 
>> > authorization endpoint will indeed return what is a standard OAuth 2.0 
>> > error response normally from the token endpoint with invalid_client or 
>> > invalid_scope error codes. And a little bit of poking at Google's device 
>> > authorization endpoint suggests it behaves similarly. I suspect it's 
>> > pretty typical.
>> >
>> >
>> >
>> > On Fri, Mar 8, 2019 at 5:28 AM Emond Papegaaij  
>> > wrote:
>> >>
>> >> Dear all,
>> >>
>> >> I'm working on an implementation of the OAuth 2.0 Device Flow for 
>> >> Browserless
>> >> and Input Constrained Devices and noticed a possible omission in the spec.
>> >> Section 3.2 describes the Device Authorization Response, but only the 
>> >> success
>> >> response is specified, not the error response. I would have expected a
>> >> standard OAuth 2.0 error response, probably with the following error 
>> >> codes:
>> >> invalid_request, invalid_client and invalid_scope.
>> >>
>> >> Best regards,
>> >> Emond Papegaaij
>> >> Topicus KeyHub
>> >>
>> >>
>> >> ___
>> >> 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 

[OAUTH-WG] Typo in Device flow 5.2

[Emond Papegaaij]

Hi all,

It seems the word 'no' is missing in section 5.2 of the OAuth 2.0 Device flow:

As the device code is not displayed to the user and thus there are
*NO* usability considerations on the length, a very high entropy code
SHOULD be used.

Best regards,
Emond Papegaaij
Topicus KeyHub

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Client authentication in the Device Authorization Request

[Brian Campbell]

All sounds good to me. Thanks again for picking this one up quickly.

On Mon, Mar 11, 2019 at 2:43 PM William Denniss  wrote:

>
>
> On Mon, Mar 11, 2019 at 1:21 PM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
>> And thank you, William, for being responsive about it.
>>
>>
>> On Mon, Mar 11, 2019 at 1:18 PM William Denniss > 40google@dmarc.ietf.org> wrote:
>>
>>> Thank you Brian for raising this.
>>>
>>> Yes, the expectation I believe is to follow the same approach as the
>>> token endpoint. As the spec is primarily for public clients, that's what we
>>> documented explicitly but it's worth calling out.
>>>
>>> Would the following text suffice in order to "inherit" the client
>>> authentication requirements of the token endpoint do you think?
>>>
>>> "The client authentication requirements of Section 3.2.1 of RFC6749
>>> apply to requests on this endpoint."
>>>
>>
>> I think so, yes.
>>
>> Although given the primary focus being for public clients, it might be
>> helpful to have a little qualifying text here catering to that most common
>> case. I guess I'm just looking to try and avoid folks mistakenly
>> interpreting that to mean that client authentication is always required and
>> so somehow public clients can't do this flow. Something like the following
>> (wording could maybe be improved but hopefully conveys the idea):
>>
>> 'The client authentication requirements of Section 3.2.1 of RFC6749 apply
>> to requests on this endpoint, which means that confidential clients (those
>> that have established client credentials) authenticate in the same manner
>> as when making requests to the token endpoint and public clients provide
>> the "client_id" parameter to identify themselves.'
>>
>>
>
> The context helps, thanks for the suggested text, I used it and it's
> staged locally now.
>
>
>>
>>
>>> Then there's the matter of the REQUIRED "client_id" parameter. Perhaps
>>> we could say "REQUIRED, unless the client authenticates per Section 2.3 of
>>> RFC6749"
>>>
>>
>> I kinda prefer the text you have already in section 3.4:
>>
>>   " client_id
>>   REQUIRED, if the client is not authenticating with the
>>   authorization server as described in Section 3.2.1. of [RFC6749]."
>>
>>
> hah yeah I prefer that construction too, forgot I'd already given it that
> treatment elsewhere.
>
> Also staged locally.
>
> Thanks again for reporting this!
>
>
>>
>>
>>>
>>> On Mon, Mar 11, 2019 at 10:30 AM Phil Hunt  wrote:
>>>
 +1 to using same authentication requirements as for token endpoint.

 Phil

 On Mar 11, 2019, at 10:27 AM, George Fletcher <
 gffletch=40aol@dmarc.ietf.org> wrote:

 +1

 to using the same client authn method as for the /token endpoint

 On 3/11/19 12:31 PM, Brian Campbell wrote:



 On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan 
 wrote:

> Strike that, it should maybe just use the registered auth method for
> the token endpoint?
>

 Yeah, that's what I'd think would be the way to go.


>
> If there's auth we should also make it clear that client_id should not
> be omitted from the request body and it must be the same as the one
> provided with client authentication.
>
>
 Fair point.




> S pozdravem,
> *Filip Skokan*
>
>
> On Mon, 11 Mar 2019 at 17:14, Filip Skokan  wrote:
>
>> If we're about to add client authentication for the
>> device_authorization_endpoint, i'd say we should also register for
>> device_authorization_endpoint_auth_method,
>> device_authorization_endpoint_auth_signing_alg client metadata. Maybe
>> define the default value to be "none" / not provided to be in line with 
>> the
>> late draft implementations. Wdyt?
>>
>> S pozdravem,
>> *Filip Skokan*
>>
>>
>> On Mon, 11 Mar 2019 at 17:08, Brian Campbell > 40pingidentity@dmarc.ietf.org> wrote:
>>
>>> I do realize it's very late in the process for this document but
>>> believe these omissions can be addressed in the document with only minor
>>> changes/additions and that it'd be better late than not at all..
>>>
>>> On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell <
>>> bcampb...@pingidentity.com> wrote:
>>>
 Another omission[1] (maybe, I believe it is anyway) to the Device
 Flow is that client authentication isn't defined for the device
 authorization request to device authorization endpoint.

 I suspect that it's largely an oversight because public clients are
 really the conical use-case for the device flow and no authentication 
 is
 needed or possible in that case. There are, however, likely to be cases
 where a client with credentials will do the device flow and it would be
 good for the AS to be able to properly authenticate such clients before
 setting 

Re: [OAUTH-WG] Client authentication in the Device Authorization Request

[Brian Campbell]

And thank you, William, for being responsive about it.


On Mon, Mar 11, 2019 at 1:18 PM William Denniss  wrote:

> Thank you Brian for raising this.
>
> Yes, the expectation I believe is to follow the same approach as the token
> endpoint. As the spec is primarily for public clients, that's what we
> documented explicitly but it's worth calling out.
>
> Would the following text suffice in order to "inherit" the client
> authentication requirements of the token endpoint do you think?
>
> "The client authentication requirements of Section 3.2.1 of RFC6749
> apply to requests on this endpoint."
>

I think so, yes.

Although given the primary focus being for public clients, it might be
helpful to have a little qualifying text here catering to that most common
case. I guess I'm just looking to try and avoid folks mistakenly
interpreting that to mean that client authentication is always required and
so somehow public clients can't do this flow. Something like the following
(wording could maybe be improved but hopefully conveys the idea):

'The client authentication requirements of Section 3.2.1 of RFC6749 apply
to requests on this endpoint, which means that confidential clients (those
that have established client credentials) authenticate in the same manner
as when making requests to the token endpoint and public clients provide
the "client_id" parameter to identify themselves.'



> Then there's the matter of the REQUIRED "client_id" parameter. Perhaps we
> could say "REQUIRED, unless the client authenticates per Section 2.3 of
> RFC6749"
>

I kinda prefer the text you have already in section 3.4:

  " client_id
  REQUIRED, if the client is not authenticating with the
  authorization server as described in Section 3.2.1. of [RFC6749]."



>
> On Mon, Mar 11, 2019 at 10:30 AM Phil Hunt  wrote:
>
>> +1 to using same authentication requirements as for token endpoint.
>>
>> Phil
>>
>> On Mar 11, 2019, at 10:27 AM, George Fletcher <
>> gffletch=40aol@dmarc.ietf.org> wrote:
>>
>> +1
>>
>> to using the same client authn method as for the /token endpoint
>>
>> On 3/11/19 12:31 PM, Brian Campbell wrote:
>>
>>
>>
>> On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan  wrote:
>>
>>> Strike that, it should maybe just use the registered auth method for the
>>> token endpoint?
>>>
>>
>> Yeah, that's what I'd think would be the way to go.
>>
>>
>>>
>>> If there's auth we should also make it clear that client_id should not
>>> be omitted from the request body and it must be the same as the one
>>> provided with client authentication.
>>>
>>>
>> Fair point.
>>
>>
>>
>>
>>> S pozdravem,
>>> *Filip Skokan*
>>>
>>>
>>> On Mon, 11 Mar 2019 at 17:14, Filip Skokan  wrote:
>>>
 If we're about to add client authentication for the
 device_authorization_endpoint, i'd say we should also register for
 device_authorization_endpoint_auth_method,
 device_authorization_endpoint_auth_signing_alg client metadata. Maybe
 define the default value to be "none" / not provided to be in line with the
 late draft implementations. Wdyt?

 S pozdravem,
 *Filip Skokan*


 On Mon, 11 Mar 2019 at 17:08, Brian Campbell >>> 40pingidentity@dmarc.ietf.org> wrote:

> I do realize it's very late in the process for this document but
> believe these omissions can be addressed in the document with only minor
> changes/additions and that it'd be better late than not at all..
>
> On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell <
> bcampb...@pingidentity.com> wrote:
>
>> Another omission[1] (maybe, I believe it is anyway) to the Device
>> Flow is that client authentication isn't defined for the device
>> authorization request to device authorization endpoint.
>>
>> I suspect that it's largely an oversight because public clients are
>> really the conical use-case for the device flow and no authentication is
>> needed or possible in that case. There are, however, likely to be cases
>> where a client with credentials will do the device flow and it would be
>> good for the AS to be able to properly authenticate such clients before
>> setting up and saving the state for the transaction. Having normal client
>> authentication at device authorization endpoint also brings better
>> consistency to client identification/authentication for requests made
>> directly from client to AS.
>>
>>
>> [1] error responses from the device authorization endpoint should
>> probably also be defined
>> https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4
>> 
>>
>>
> *CONFIDENTIALITY NOTICE: This 

[OAUTH-WG] Nested JWT draft

[Rifaat Shekh-Yusef]

Hi,

I have just submitted the following short draft with some *initial thoughts
*on extending the Nested JWT concept defined in the RFC7519, to allow the
enclosing JWT to have its own Claims Set.
https://www.ietf.org/id/draft-yusef-oauth-nested-jwt-00.txt

I would appreciate any reviews and comments about this draft.

Regards,
 Rifaat
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Digest, Vol 125, Issue 10

[이천욱]

ation endpoint will indeed return what is a standard OAuth 2.0
> > error response normally from the token endpoint with invalid_client or
> > invalid_scope error codes. And a little bit of poking at Google's device
> > authorization endpoint suggests it behaves similarly. I suspect it's
> pretty
> > typical.
> > >
> > >
> > >
> > > On Fri, Mar 8, 2019 at 5:28 AM Emond Papegaaij <
> > emond.papega...@gmail.com> wrote:
> > >>
> > >> Dear all,
> > >>
> > >> I'm working on an implementation of the OAuth 2.0 Device Flow for
> > Browserless
> > >> and Input Constrained Devices and noticed a possible omission in the
> > spec.
> > >> Section 3.2 describes the Device Authorization Response, but only the
> > success
> > >> response is specified, not the error response. I would have expected a
> > >> standard OAuth 2.0 error response, probably with the following error
> > codes:
> > >> invalid_request, invalid_client and invalid_scope.
> > >>
> > >> Best regards,
> > >> Emond Papegaaij
> > >> Topicus KeyHub
> > >>
> > >>
> > >> ___
> > >> 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
> >
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190311/12994b9b/attachment.html
> >
>
> --
>
> Message: 2
> Date: Mon, 11 Mar 2019 10:30:08 -0700
> From: Phil Hunt 
> To: George Fletcher 
> Cc: Brian Campbell ,
> Filip Skokan , oauth 
> Subject: Re: [OAUTH-WG] Client authentication in the Device
> Authorization Request
> Message-ID: <710acba5-c43d-4396-a3ae-9d7156204...@oracle.com>
> Content-Type: text/plain; charset="us-ascii"
>
> +1 to using same authentication requirements as for token endpoint.
>
> Phil
>
> > On Mar 11, 2019, at 10:27 AM, George Fletcher  40aol@dmarc.ietf.org> wrote:
> >
> > +1
> >
> > to using the same client authn method as for the /token endpoint
> >
> >> On 3/11/19 12:31 PM, Brian Campbell wrote:
> >>
> >>
> >>> On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan 
> wrote:
> >>> Strike that, it should maybe just use the registered auth method for
> the token endpoint?
> >>
> >> Yeah, that's what I'd think would be the way to go.
> >>
> >>>
> >>> If there's auth we should also make it clear that client_id should not
> be omitted from the request body and it must be the same as the one
> provided with client authentication.
> >>>
> >>
> >> Fair point.
> >>
> >>
> >>
> >>> S pozdravem,
> >>> Filip Skokan
> >>>
> >>>
> >>>> On Mon, 11 Mar 2019 at 17:14, Filip Skokan 
> wrote:
> >>>> If we're about to add client authentication for the
> device_authorization_endpoint, i'd say we should also register for
> device_authorization_endpoint_auth_method,
> device_authorization_endpoint_auth_signing_alg client metadata. Maybe
> define the default value to be "none" / not provided to be in line with the
> late draft implementations. Wdyt?
> >>>>
> >>>> S pozdravem,
> >>>> Filip Skokan
> >>>>
> >>>>
> >>>>> On Mon, 11 Mar 2019 at 17:08, Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
> >>>>> I do realize it's very late in the process for this document but
> believe these omissions can be addressed in the document with only minor
> changes/additions and that it'd be better late than not at all..
> >>>>>
> >>>>>> On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell <

Re: [OAUTH-WG] Client authentication in the Device Authorization Request

[Phil Hunt]

+1 to using same authentication requirements as for token endpoint. 

Phil

> On Mar 11, 2019, at 10:27 AM, George Fletcher 
>  wrote:
> 
> +1
> 
> to using the same client authn method as for the /token endpoint
> 
>> On 3/11/19 12:31 PM, Brian Campbell wrote:
>> 
>> 
>>> On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan  wrote:
>>> Strike that, it should maybe just use the registered auth method for the 
>>> token endpoint?
>> 
>> Yeah, that's what I'd think would be the way to go. 
>>  
>>> 
>>> If there's auth we should also make it clear that client_id should not be 
>>> omitted from the request body and it must be the same as the one provided 
>>> with client authentication.
>>> 
>> 
>> Fair point. 
>> 
>> 
>>  
>>> S pozdravem,
>>> Filip Skokan
>>> 
>>> 
 On Mon, 11 Mar 2019 at 17:14, Filip Skokan  wrote:
 If we're about to add client authentication for the 
 device_authorization_endpoint, i'd say we should also register for 
 device_authorization_endpoint_auth_method, 
 device_authorization_endpoint_auth_signing_alg client metadata. Maybe 
 define the default value to be "none" / not provided to be in line with 
 the late draft implementations. Wdyt?
 
 S pozdravem,
 Filip Skokan
 
 
> On Mon, 11 Mar 2019 at 17:08, Brian Campbell 
>  wrote:
> I do realize it's very late in the process for this document but believe 
> these omissions can be addressed in the document with only minor 
> changes/additions and that it'd be better late than not at all.. 
> 
>> On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell 
>>  wrote:
>> Another omission[1] (maybe, I believe it is anyway) to the Device Flow 
>> is that client authentication isn't defined for the device authorization 
>> request to device authorization 
>> endpoint. 
>> 
>> I suspect that it's largely an oversight because public clients are 
>> really the conical use-case for the device flow and no authentication is 
>> needed or possible in that case. There are, however, likely to be cases 
>> where a client with credentials will do the device flow and it would be 
>> good for the AS to be able to properly authenticate such clients before 
>> setting up and saving the state for the transaction. Having normal 
>> client authentication at device authorization endpoint also brings 
>> better consistency to client identification/authentication for requests 
>> made directly from client to AS.  
>> 
>> 
>> [1] error responses from the device authorization endpoint should 
>> probably also be defined 
>> https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4 
>> 
> 
> 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
>>> ___
>>> 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
> 
> -- 
> Identity Standards Architect
> Verizon Media Work: george.fletc...@oath.com
> Mobile: +1-703-462-3494   Twitter: http://twitter.com/gffletch
> Office: +1-703-265-2544   Photos: http://georgefletcher.photography
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA=T9FBaSmKjH9DP1tZy7yS2PWNPsktsU0izt30MhOcMpw=A-TWytTVW596UG0zc6oz1rozU_auZJ0bIPSGqtXnTGA=
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Device flow error response

[Filip Skokan]

Hi Emond,

the way i approached implementation of device flow into an OIDC server was
to allow all already registered and handled parameters excluding the ones
[1] that really don't make sense for the flow at the device authorization
endpoint.

What can be validated at the device authorization endpoint time is,
everything else runs as part of the regular authorization pipeline for
which i also construct the request based on the params saved together with
the device code backend model. Everything else that depends on the actual
device where authnz happens is processed as part of the web request
following the user code submission. When errors occur that cannot be
resolved with user interaction the error is assigned to the device code and
returned to the device with the next poll. I did not exclude prompt:none,
as the pipeline processing starts after the submission it's possible that
no prompt will occur there, but i can see how it may be weird. Yes the
result at the token endpoint will include an id token if the scope included
`openid` as one would expect, just like it will include a refresh token if
`offline_access` is present. `resource` specifically is available as per
the resource indicator spec at device authorization as well as token
endpoints.

I guess this is very similar to what you're thinking.

I don't think we need to (and can for that matter) enumerate all possible
OAuth2.0 extensions in the specification.

[1] web_message_uri, web_message_target, response_type, response_mode,
state, redirect_uri

S pozdravem,
*Filip Skokan*


On Mon, 11 Mar 2019 at 15:02, Emond Papegaaij 
wrote:

> Yes, that's how I implemented it as well. I return 'invalid_request'
> when the client_id is missing entirely.
>
> Do you have any thoughts how this specification should work in
> combination with other specs, such as OIDC? For example, the OIDC
> Authentication Request specifies several additional parameters, some
> of which may be applicable for the device flow as well. Can the device
> flow be used to obtain an ID token? How should parameters like
> 'max_age', 'id_token_hint' and 'claims' be processed? My plan was to
> construct a pseudo-authentication/authorization request using the
> parameters specified at the device authorization endpoint and apply
> these parameters during the user interaction. Some parameters, such as
> 'prompt=3Dnone', do not make much sense though.
>
> I think it may be a good idea to describe how this spec is supposed to
> interoperate with other specifications, especially those that extend
> the Authorization Endpoint. This definition can never be complete, as
> new specs will be defined after this one, but it can at least try to
> describe the general rules that apply.
>
> PS. Other specifications also define additional parameters that may be
> useful, such as: 'resource' from Resource Indicators for OAuth 2.0 and
> 'include_granted_scopes' from OAuth 2.0 Incremental Authorization.
>
> Best regards,
> Emond Papegaaij
> Topicus KeyHub
>
> On Fri, Mar 8, 2019 at 10:24 PM Brian Campbell
>  wrote:
> >
> > While probably not terribly important from an interoperability
> perspective, I agree that does seem like an omission.
> >
> > I took a quick look at our implementation and bad requests to the device
> authorization endpoint will indeed return what is a standard OAuth 2.0
> error response normally from the token endpoint with invalid_client or
> invalid_scope error codes. And a little bit of poking at Google's device
> authorization endpoint suggests it behaves similarly. I suspect it's pretty
> typical.
> >
> >
> >
> > On Fri, Mar 8, 2019 at 5:28 AM Emond Papegaaij <
> emond.papega...@gmail.com> wrote:
> >>
> >> Dear all,
> >>
> >> I'm working on an implementation of the OAuth 2.0 Device Flow for
> Browserless
> >> and Input Constrained Devices and noticed a possible omission in the
> spec.
> >> Section 3.2 describes the Device Authorization Response, but only the
> success
> >> response is specified, not the error response. I would have expected a
> >> standard OAuth 2.0 error response, probably with the following error
> codes:
> >> invalid_request, invalid_client and invalid_scope.
> >>
> >> Best regards,
> >> Emond Papegaaij
> >> Topicus KeyHub
> >>
> >>
> >> ___
> >> 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
>
___

Re: [OAUTH-WG] Client authentication in the Device Authorization Request

[George Fletcher]

+1

to using the same client authn method as for the /token endpoint

On 3/11/19 12:31 PM, Brian Campbell wrote:



On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan > wrote:


Strike that, it should maybe just use the registered auth method
for the token endpoint?


Yeah, that's what I'd think would be the way to go.


If there's auth we should also make it clear that client_id should
not be omitted from the request body and it must be the same as
the one provided with client authentication.


Fair point.


S pozdravem,
*Filip Skokan*


On Mon, 11 Mar 2019 at 17:14, Filip Skokan mailto:panva...@gmail.com>> wrote:

If we're about to add client authentication for the
device_authorization_endpoint, i'd say we should also register
for device_authorization_endpoint_auth_method,
device_authorization_endpoint_auth_signing_alg client
metadata. Maybe define the default value to be "none" / not
provided to be in line with the late draft implementations. Wdyt?

S pozdravem,
*Filip Skokan*


On Mon, 11 Mar 2019 at 17:08, Brian Campbell
mailto:40pingidentity@dmarc.ietf.org>> wrote:

I do realize it's very late in the process for this
document but believe these omissions can be addressed in
the document with only minor changes/additions and that
it'd be better late than not at all..

On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell
mailto:bcampb...@pingidentity.com>> wrote:

Another omission[1] (maybe, I believe it is anyway) to
the Device Flow is that client authentication isn't
defined for the device authorization request to device
authorization endpoint.

I suspect that it's largely an oversight because
public clients are really the conical use-case for the
device flow and no authentication is needed or
possible in that case. There are, however, likely to
be cases where a client with credentials will do the
device flow and it would be good for the AS to be able
to properly authenticate such clients before setting
up and saving the state for the transaction. Having
normal client authentication at device authorization
endpoint also brings better consistency to client
identification/authentication for requests made
directly from client to AS.


[1] error responses from the device authorization
endpoint should probably also be defined

https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4



/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

___
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


--
Identity Standards Architect
Verizon Media Work: george.fletc...@oath.com
Mobile: +1-703-462-3494   Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544   Photos: http://georgefletcher.photography

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Client authentication in the Device Authorization Request

[Brian Campbell]

On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan  wrote:

> Strike that, it should maybe just use the registered auth method for the
> token endpoint?
>

Yeah, that's what I'd think would be the way to go.


>
> If there's auth we should also make it clear that client_id should not be
> omitted from the request body and it must be the same as the one provided
> with client authentication.
>
>
Fair point.




> S pozdravem,
> *Filip Skokan*
>
>
> On Mon, 11 Mar 2019 at 17:14, Filip Skokan  wrote:
>
>> If we're about to add client authentication for the
>> device_authorization_endpoint, i'd say we should also register for
>> device_authorization_endpoint_auth_method,
>> device_authorization_endpoint_auth_signing_alg client metadata. Maybe
>> define the default value to be "none" / not provided to be in line with the
>> late draft implementations. Wdyt?
>>
>> S pozdravem,
>> *Filip Skokan*
>>
>>
>> On Mon, 11 Mar 2019 at 17:08, Brian Campbell > 40pingidentity@dmarc.ietf.org> wrote:
>>
>>> I do realize it's very late in the process for this document but believe
>>> these omissions can be addressed in the document with only minor
>>> changes/additions and that it'd be better late than not at all..
>>>
>>> On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell <
>>> bcampb...@pingidentity.com> wrote:
>>>
 Another omission[1] (maybe, I believe it is anyway) to the Device Flow
 is that client authentication isn't defined for the device authorization
 request to device authorization endpoint.

 I suspect that it's largely an oversight because public clients are
 really the conical use-case for the device flow and no authentication is
 needed or possible in that case. There are, however, likely to be cases
 where a client with credentials will do the device flow and it would be
 good for the AS to be able to properly authenticate such clients before
 setting up and saving the state for the transaction. Having normal client
 authentication at device authorization endpoint also brings better
 consistency to client identification/authentication for requests made
 directly from client to AS.


 [1] error responses from the device authorization endpoint should
 probably also be defined
 https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4


>>> *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
>>>
>> ___
> 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

Re: [OAUTH-WG] Client authentication in the Device Authorization Request

[Filip Skokan]

Strike that, it should maybe just use the registered auth method for the
token endpoint?

If there's auth we should also make it clear that client_id should not be
omitted from the request body and it must be the same as the one provided
with client authentication.

S pozdravem,
*Filip Skokan*


On Mon, 11 Mar 2019 at 17:14, Filip Skokan  wrote:

> If we're about to add client authentication for the
> device_authorization_endpoint, i'd say we should also register for
> device_authorization_endpoint_auth_method,
> device_authorization_endpoint_auth_signing_alg client metadata. Maybe
> define the default value to be "none" / not provided to be in line with the
> late draft implementations. Wdyt?
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Mon, 11 Mar 2019 at 17:08, Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
>> I do realize it's very late in the process for this document but believe
>> these omissions can be addressed in the document with only minor
>> changes/additions and that it'd be better late than not at all..
>>
>> On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell <
>> bcampb...@pingidentity.com> wrote:
>>
>>> Another omission[1] (maybe, I believe it is anyway) to the Device Flow
>>> is that client authentication isn't defined for the device authorization
>>> request to device authorization endpoint.
>>>
>>> I suspect that it's largely an oversight because public clients are
>>> really the conical use-case for the device flow and no authentication is
>>> needed or possible in that case. There are, however, likely to be cases
>>> where a client with credentials will do the device flow and it would be
>>> good for the AS to be able to properly authenticate such clients before
>>> setting up and saving the state for the transaction. Having normal client
>>> authentication at device authorization endpoint also brings better
>>> consistency to client identification/authentication for requests made
>>> directly from client to AS.
>>>
>>>
>>> [1] error responses from the device authorization endpoint should
>>> probably also be defined
>>> https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4
>>>
>>>
>> *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
>>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Client authentication in the Device Authorization Request

[Filip Skokan]

If we're about to add client authentication for the
device_authorization_endpoint, i'd say we should also register for
device_authorization_endpoint_auth_method,
device_authorization_endpoint_auth_signing_alg client metadata. Maybe
define the default value to be "none" / not provided to be in line with the
late draft implementations. Wdyt?

S pozdravem,
*Filip Skokan*


On Mon, 11 Mar 2019 at 17:08, Brian Campbell  wrote:

> I do realize it's very late in the process for this document but believe
> these omissions can be addressed in the document with only minor
> changes/additions and that it'd be better late than not at all..
>
> On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell <
> bcampb...@pingidentity.com> wrote:
>
>> Another omission[1] (maybe, I believe it is anyway) to the Device Flow is
>> that client authentication isn't defined for the device authorization
>> request to device authorization endpoint.
>>
>> I suspect that it's largely an oversight because public clients are
>> really the conical use-case for the device flow and no authentication is
>> needed or possible in that case. There are, however, likely to be cases
>> where a client with credentials will do the device flow and it would be
>> good for the AS to be able to properly authenticate such clients before
>> setting up and saving the state for the transaction. Having normal client
>> authentication at device authorization endpoint also brings better
>> consistency to client identification/authentication for requests made
>> directly from client to AS.
>>
>>
>> [1] error responses from the device authorization endpoint should
>> probably also be defined
>> https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4
>>
>>
> *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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Client authentication in the Device Authorization Request

[Brian Campbell]

I do realize it's very late in the process for this document but believe
these omissions can be addressed in the document with only minor
changes/additions and that it'd be better late than not at all.

On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell 
wrote:

> Another omission[1] (maybe, I believe it is anyway) to the Device Flow is
> that client authentication isn't defined for the device authorization
> request to device authorization endpoint.
>
> I suspect that it's largely an oversight because public clients are really
> the conical use-case for the device flow and no authentication is needed or
> possible in that case. There are, however, likely to be cases where a
> client with credentials will do the device flow and it would be good for
> the AS to be able to properly authenticate such clients before setting up
> and saving the state for the transaction. Having normal client
> authentication at device authorization endpoint also brings better
> consistency to client identification/authentication for requests made
> directly from client to AS.
>
>
> [1] error responses from the device authorization endpoint should probably
> also be defined
> https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4
>
>

-- 
_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

[OAUTH-WG] Client authentication in the Device Authorization Request

[Brian Campbell]

Another omission[1] (maybe, I believe it is anyway) to the Device Flow is
that client authentication isn't defined for the device authorization
request to device authorization endpoint.

I suspect that it's largely an oversight because public clients are really
the conical use-case for the device flow and no authentication is needed or
possible in that case. There are, however, likely to be cases where a
client with credentials will do the device flow and it would be good for
the AS to be able to properly authenticate such clients before setting up
and saving the state for the transaction. Having normal client
authentication at device authorization endpoint also brings better
consistency to client identification/authentication for requests made
directly from client to AS.


[1] error responses from the device authorization endpoint should probably
also be defined
https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4

-- 
_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] OAuth 2.0 Device flow error response

[Emond Papegaaij]

Yes, that's how I implemented it as well. I return 'invalid_request'
when the client_id is missing entirely.

Do you have any thoughts how this specification should work in
combination with other specs, such as OIDC? For example, the OIDC
Authentication Request specifies several additional parameters, some
of which may be applicable for the device flow as well. Can the device
flow be used to obtain an ID token? How should parameters like
'max_age', 'id_token_hint' and 'claims' be processed? My plan was to
construct a pseudo-authentication/authorization request using the
parameters specified at the device authorization endpoint and apply
these parameters during the user interaction. Some parameters, such as
'prompt=3Dnone', do not make much sense though.

I think it may be a good idea to describe how this spec is supposed to
interoperate with other specifications, especially those that extend
the Authorization Endpoint. This definition can never be complete, as
new specs will be defined after this one, but it can at least try to
describe the general rules that apply.

PS. Other specifications also define additional parameters that may be
useful, such as: 'resource' from Resource Indicators for OAuth 2.0 and
'include_granted_scopes' from OAuth 2.0 Incremental Authorization.

Best regards,
Emond Papegaaij
Topicus KeyHub

On Fri, Mar 8, 2019 at 10:24 PM Brian Campbell
 wrote:
>
> While probably not terribly important from an interoperability perspective, I 
> agree that does seem like an omission.
>
> I took a quick look at our implementation and bad requests to the device 
> authorization endpoint will indeed return what is a standard OAuth 2.0 error 
> response normally from the token endpoint with invalid_client or 
> invalid_scope error codes. And a little bit of poking at Google's device 
> authorization endpoint suggests it behaves similarly. I suspect it's pretty 
> typical.
>
>
>
> On Fri, Mar 8, 2019 at 5:28 AM Emond Papegaaij  
> wrote:
>>
>> Dear all,
>>
>> I'm working on an implementation of the OAuth 2.0 Device Flow for Browserless
>> and Input Constrained Devices and noticed a possible omission in the spec.
>> Section 3.2 describes the Device Authorization Response, but only the success
>> response is specified, not the error response. I would have expected a
>> standard OAuth 2.0 error response, probably with the following error codes:
>> invalid_request, invalid_client and invalid_scope.
>>
>> Best regards,
>> Emond Papegaaij
>> Topicus KeyHub
>>
>>
>> ___
>> 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

[OAUTH-WG] draft-ietf-oauth-pop-key-distribution-06

[Hannes Tschofenig]

Well. I made a mistake with version -05.
Now there is a version -06

Ciao
Hannes

From: OAuth  On Behalf Of Hannes Tschofenig
Sent: Montag, 11. März 2019 13:52
To: oauth 
Subject: [OAUTH-WG] draft-ietf-oauth-pop-key-distribution-05

I just submitted -05 of the draft. The updates are limited to author info 
updates and minor editorial nits..

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-06.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

Title   : OAuth 2.0 Proof-of-Possession: Authorization Server 
to Client Key Distribution
Authors : John Bradley
  Phil Hunt
  Michael B. Jones
  Hannes Tschofenig
  Mihaly Meszaros
Filename: draft-ietf-oauth-pop-key-distribution-06.txt
Pages   : 17
Date: 2019-03-11

Abstract:
   RFC 6750 specified the bearer token concept for securing access to
   protected resources.  Bearer tokens need to be protected in transit
   as well as at rest.  When a client requests access to a protected
   resource it hands-over the bearer token to the resource server.

   The OAuth 2.0 Proof-of-Possession security concept extends bearer
   token security and requires the client to demonstrate possession of a
   key when accessing a protected resource.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-06
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-pop-key-distribution-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-key-distribution-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] OAuth WG Virtual meeting this week

[Rifaat Shekh-Yusef]

All,

The meeting time for this week has not changed, which means it will be one
hour later for people that moved to Daylight Savings Time (1:00pm Eastern
Time).

Regards,
 Rifaat
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] draft-ietf-oauth-pop-key-distribution-05

[Hannes Tschofenig]

I just submitted -05 of the draft. The updates are limited to author info 
updates and minor editorial nits.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-05.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

Title   : OAuth 2.0 Proof-of-Possession: Authorization Server 
to Client Key Distribution
Authors : John Bradley
  Phil Hunt
  Michael B. Jones
  Hannes Tschofenig
  Mihaly Meszaros
Filename: draft-ietf-oauth-pop-key-distribution-05.txt
Pages   : 15
Date: 2019-03-11

Abstract:
   RFC 6750 specified the bearer token concept for securing access to
   protected resources.  Bearer tokens need to be protected in transit
   as well as at rest.  When a client requests access to a protected
   resource it hands-over the bearer token to the resource server.

   The OAuth 2.0 Proof-of-Possession security concept extends bearer
   token security and requires the client to demonstrate possession of a
   key when accessing a protected resource.

   This document describes how the client requests and obtains a PoP
   access token from the authorization server for use with HTTPS-based
   transport.  Alternative transports, for example using the Constrained
   Application Protocol (CoAP), have been specified in companion
   specifications.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-05
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-pop-key-distribution-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-key-distribution-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth