Hello.You need not send email. Thank you. 2019년 3월 12일 (화) 오전 2:31, <[email protected]>님이 작성:
> Send OAuth mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: OAuth 2.0 Device flow error response (Filip Skokan) > 2. Re: Client authentication in the Device Authorization Request > (Phil Hunt) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 11 Mar 2019 18:28:57 +0100 > From: Filip Skokan <[email protected]> > To: Emond Papegaaij <[email protected]> > Cc: oauth <[email protected]> > Subject: Re: [OAUTH-WG] OAuth 2.0 Device flow error response > Message-ID: > <CALAqi_9dDuZxuh0gdLaHuFq_UAQ2fTjq= > [email protected]> > Content-Type: text/plain; charset="utf-8" > > 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 <[email protected]> > 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 > > <[email protected]> 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 < > > [email protected]> 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 > > >> [email protected] > > >> 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 > > [email protected] > > 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 <[email protected]> > To: George Fletcher <[email protected]> > Cc: Brian Campbell <[email protected]>, > Filip Skokan <[email protected]>, oauth <[email protected]> > Subject: Re: [OAUTH-WG] Client authentication in the Device > Authorization Request > Message-ID: <[email protected]> > 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 <gffletch= > [email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 <bcampbell= > [email protected]> 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 < > [email protected]> 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 > >>>>> [email protected] > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>> _______________________________________________ > >>> OAuth mailing list > >>> [email protected] > >>> 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 > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/oauth > > > > -- > > Identity Standards Architect > > Verizon Media Work: [email protected] > > Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch > > Office: +1-703-265-2544 Photos: > http://georgefletcher.photography > > _______________________________________________ > > OAuth mailing list > > [email protected] > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=T9FBaSmKjH9DP1tZy7yS2PWNPsktsU0izt30MhOcMpw&s=A-TWytTVW596UG0zc6oz1rozU_auZJ0bIPSGqtXnTGA&e= > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190311/4250bfe2/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 125, Issue 10 > ************************************** >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
