Re: [OAUTH-WG] PAR - Can AS/client require request object?
+1 for require_request_objects AS metadata parameter. The natural place for this parameter for me would be the JAR spec . Vladimir On 12/05/2020 09:27, Torsten Lodderstedt wrote: > Hi all, > > I initially raised the question whether the AS should be able to require > request objects for all clients (in the same way as we decided to let the AS > required PAR for all clients) but this topic was never discussed later on. > > I suggest to add a server metadata parameter “require_request_objects” so the > AS can indicate its policy to clients. > > I think the best place to define this parameter would be JAR, if that is not > possible any longer, we could use a different PAR-specific name and add it to > PAR. > > What do you think? > > best regards, > Torsten. > >> On 1. May 2020, at 17:56, Mike Jones >> wrote: >> >> Works for me. >> >> >> >> From: OAuth On Behalf Of Torsten Lodderstedt >> Sent: Friday, May 1, 2020 2:51 AM >> To: Brian Campbell >> Cc: oauth >> Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object? >> >> >> >> Filip´s proposal works for me. >> >> >> >> Are there any objections? >> >> >> >> Brian Campbell schrieb am Mo. >> 27. Apr. 2020 um 20:57: >> >> While there are certainly different permutations and contexts of use that >> could be imagine, I tend to agree with Filip here in not seeing a strong >> need to define new PAR specific metadata around signing/encryption of the >> request object. >> >> >> >> On Mon, Apr 27, 2020 at 2:35 AM Filip Skokan wrote: >> >> Considering there's going to be a setting that forces clients to use PAR >> (other mailinglist thread), then we should rely on the existing >> `request_object_signing_alg` presence to indicate a Request Object must be >> used (as suggested by this upcoming OIDC Core errata), regardless of it >> being PAR or JAR. I don't see the need for a PAR specific metadata, for one >> - implementations wouldn't be easily able to re-use of existing pipelines, >> two - yes the contexts differ but do you think clients will be using both >> channels at the same time? And even if so, the Request Object is the same >> therefore its applicable to both channels the same. >> >> >> Best, >> Filip Skokan >> >> >> >> >> >> On Sun, 26 Apr 2020 at 17:09, Torsten Lodderstedt >> wrote: >> >> Hi all, >> >> this is one of the topics we quickly flipped through in the virtual meeting >> last week. >> >> I see the following open questions: >> - Can the client require its instances to use request objects only. >> - Are there further requirements on the properties of these objects? Signed >> only, Signed and encrypted, algorithms? >> - Can an AS require ALL clients to use request objects only? >> - Further requirements here as well? >> - Is this tied to PAR or relevant for JAR as well? >> >> In my opinion, client as well as AS should be able to control enforced use >> of request objects. >> >> I could imagine the setting for JAR request objects (“request" parameter) >> and request objects in the PAR context differ, as the first case goes >> through the user’s browser whereas the PAR case goes direct from client to >> AS via a TLS protected channel. I therefore feel the settings should be PAR >> specific. >> >> What do you think? >> >> best regards, >> Torsten. >> ___ >> 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 -- Vladimir Dzhuvinov smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
Hi all,
I would also like to thank everybody for the substantial discussion.
The proposed change for Section 4.1.2.1 works for me (as already stated). I’m
not fully comfortable with the proposed change for Section 9.7 for the
following reasons:
- The text is weaker than Section 4.1.2.1 since it RECOMMENDS use of PKCE
instead of requiring it (with a well-defined exception).
- Given the latest findings re nonce I don’t feel comfortable with recommending
any mechanism that this WG is not responsible for and thus did not conduct the
security threat analysis for. I think the better way for us as WG is to define
the extension point for other mechanisms. The OpenID Foundation (or any other
body) can then fill in and issue a statement that nonce (or another suitable
mechanism) fulfils the requirements of the extension point.
Based on this considerations, I propose the following text for Section 9.7:
Clients MUST prevent injection (replay) of authorization codes into
the authorization response by attackers. Public clients MUST use the
"code_challenge” with a transaction-specific value that is
securely bound to the client and the user agent in which the
transaction was started. Confidential clients MUST use
the “code_challenge” in the same way or other suitable mechanisms to
mitigate authorization code injection.
This text follows the logic in Section 4.1.2.1 and allows use of the nonce for
confidential clients.
best regards,
Torsten.
> On 12. May 2020, at 02:21, Mike Jones
> wrote:
>
> That works for me. Thanks all for the useful back-and-forth that got us to
> this point of clarity. I suspect many of us learned things along the way; I
> know that I did!
>
>Cheers,
>-- Mike
>
> From: Aaron Parecki
> Sent: Monday, May 11, 2020 4:55 PM
> To: OAuth WG
> Cc: Neil Madden ; Mike Jones
>
> Subject: Re: [OAUTH-WG] proposed resolution for PKCE in OAuth 2.1
>
> Thank you Neil.
>
> To address Mike's concerns in the previous threads, I would like to also
> update section 9.7 with the following text:
>
> Clients MUST prevent injection (replay) of authorization codes into the
> authorization response by attackers. The use of the `code_challenge`
> parameter is RECOMMENDED to this end. For confidential clients, the
> OpenID Connect `nonce` parameter and ID Token Claim {{OpenID}} MAY be used
> instead of or in addition to the `code_challenge` parameter for this
> purpose. The `code_challenge` or OpenID Connect `nonce` value MUST be
> transaction-specific and securely bound to the client and the user agent
> in which the transaction was started.
>
> This change better clarifies the specific circumstances under which the
> "nonce" parameter is sufficient to protect against authorization code
> injection.
>
> Aaron Parecki
>
> On Mon, May 11, 2020 at 11:55 AM Neil Madden
> wrote:
> I am happy with this proposed wording. Thanks for updating it.
>
> — Neil
>
>
> On 11 May 2020, at 19:52, Aaron Parecki wrote:
>
> Thanks for the lively discussion around PKCE in OAuth 2.1 everyone!
>
> We would like to propose the following text, which is a slight variation from
> the text Neil proposed. This would replace the paragraph in 4.1.2.1
> (https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.1.2.1)
> that begins with "If the client does not send the "code_challenge" in the
> request..."
>
> "An AS MUST reject requests without a code_challenge from public clients, and
> MUST reject such requests from other clients unless there is reasonable
> assurance that the client mitigates authorization code injection in other
> ways. See section 9.7 for details."
>
> Section 9.7 is where the nuances of PKCE vs nonce are described.
>
> As Neil described, we believe this will allow ASs to support both OAuth 2.0
> and 2.1 clients simultaneously. The change from Neil's text is the
> clarification of which threats, and changing to MUST instead of SHOULD. The
> "MUST...unless" is more specific than "SHOULD", and since we are already
> describing the explicit exception to the rule, it's more clear as a MUST here.
>
> Aaron Parecki
>
>
>
>
> ___
> 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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Usage of Password Grant
On 2020-05-10 10:20 a.m., Aaron Parecki wrote: > Hi Beena, > > This sounds like a great use of the client credentials grant. The > password grant is being removed from OAuth 2.0 by the Security Best > Current Practice. Can you clarify what you've found useful about the > password grant that the client credentials grant doesn't solve? One nice benefit of the password grant, is that client_id is a nice, general way to trace what application did the log in. Handy for audit logs and if we ever find a security issue we could hypothetically invalidate all passwords used by the client_id that introduced the issue. The alternative is to introduce a custom parameter, but this is unlikely to work easily with existing OAuth2 implementations. So, I will miss "password". Evert ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-05-18
Just wanted to note that there is a newer -01 revision of the document on the agenda https://www.ietf.org/id/draft-ietf-oauth-dpop-01.html On Wed, May 13, 2020 at 6:16 AM IESG Secretary wrote: > The Web Authorization Protocol (oauth) Working Group will hold > a virtual interim meeting on 2020-05-18 from 18:00 to 19:00 Europe/Vienna > (16:00 to 17:00 UTC). > > Agenda: > DPOP > https://tools.ietf.org/html/draft-ietf-oauth-dpop-00 > > Information about remote participation: > https://ietf.webex.com/ietf/j.php?MTID=m2655406e74aa2b4e129a1b91a076f70b > > https://mailarchive.ietf.org/arch/msg/oauth/Fncp1uUV7yOJhflPfWvbe-gWXO0/ > > ___ > IETF-Announce mailing list > ietf-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > -- _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] OAuth 2.1 mimetype
Currently OAuth 2 uses application/json as their main mimetype for JSON responses. This has at least two drawbacks: 1. Content-negotiation is a good way to to version/alter behavior of endpoints/introduce extensions or modifications. 2. In systems that use Web Linking, it's harder to use a generic link relationship to point to an OAuth2 endpoint. I would like to define links in my system to point to endpoints where users may log in (to the authorize endpoint), or log out (the revoke endpoint). In an ideal world, I would do this with a link such as: Link: https://auth-server.example; rel="authenticate"; type="application/oauth21+json" This allows a client both figure out in a generic manner the endpoints are, and also what protocol is supported. Is there a chance that a new mimetype could be registered for OAuth 2.1? I believe this can be done in a manner that's both backwards compatible with OAuth 2, by requiring clients and servers to support 'application/json'. For instance, a server can respond with 'application/json' if it didn't receive 'application/oauth21+json' in neither a Content-Type nor Accept request header. Evert ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
Sorry for coming late in the game, but I really think that the "sub" claim should be OPTIONAL instead of REQUIRED. We are implementing OAuth 2.0 for the Norwegian health sector, where we have several resources in production already. I don't think the "sub" claim should have different meaning depending on the flow - we would prefer to omit the sub claim in cases where the resource owner isn't present. This is not possible with the current language. We would like to be able to choose if and how we use the "sub" - the "client_id" claim will always be present. Regards Steinar ons. 13. mai 2020 kl. 16:07 skrev Rifaat Shekh-Yusef < rifaat.s.i...@gmail.com>: > All, > > Based on the 3rd WGLC, we believe that we have consensus to move this > document forward. > https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ > > We will be working on the shepherd write-up and then submit the document > to the IESG soon. > > Regards, > Rifaat & Hannes > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Vennlig hilsen Steinar Noem Partner Udelt AS Systemutvikler | stei...@udelt.no | h...@udelt.no | +47 955 21 620 | www.udelt.no | ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
All, Based on the 3rd WGLC, we believe that we have consensus to move this document forward. https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ We will be working on the shepherd write-up and then submit the document to the IESG soon. Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-05-18
The Web Authorization Protocol (oauth) Working Group will hold a virtual interim meeting on 2020-05-18 from 18:00 to 19:00 Europe/Vienna (16:00 to 17:00 UTC). Agenda: DPOP https://tools.ietf.org/html/draft-ietf-oauth-dpop-00 Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m2655406e74aa2b4e129a1b91a076f70b https://mailarchive.ietf.org/arch/msg/oauth/Fncp1uUV7yOJhflPfWvbe-gWXO0/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Virtual Interim meeting next Monday, May 18th -- DPOP Discussion
Hi all,
As discussed at the last virtual interim meeting call we will add another slot
next Monday to talk about DPOP. This is a continuation of the DPOP discussion
we had during one of our virtual interim meeting slots.
Please find the meeting invite in the calendar.
Ciao
Hannes & Rifaat
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.
BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:Europe Time
BEGIN:STANDARD
DTSTART:20181001T03
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:Standard Time
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20180301T02
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:Daylight Savings Time
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
CLASS:PUBLIC
DESCRIPTION:\n\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=m7210004128aa1dba87884a2c0ee806a0\nMeeting number (access code): 614 520 039\n\nMeeting password: BWsAF9rT\n\n\n\nJOIN BY PHONE\n1-650-479-3208 Call-in toll number (US/Canada) \nTap here to call (mobile phones only, hosts not supported): tel:%2B1-650-479-3208,,*01*614520039%23%23*01*\n\n\nJOIN FROM A VIDEO SYSTEM OR APPLICATION\nDial sip:614520...@ietf.webex.com\nYou can also dial 173.243.2.68 and enter your meeting number.\n\n\nJoin using Microsoft Lync or Microsoft Skype for Business\nDial sip:614520039.i...@lync.webex.com\n\n\n\nCan't join the meeting? Contact support here:\nhttps://ietf.webex.com/ietf/mc\n\n\nIMPORTANT NOTICE: Please note that this Webex service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. You should inform all meeting attendees prior to recording if you intend to record the meeting.\n
X-ALT-DESC;FMTTYPE=text/html:* {padding: 0;margin: 0;}table { border-collapse: separate; width =100%; border: 0; border-spacing: 0;}tr { line-height: 18px;}a, td { font-size: 14px; font-family: Arial; color: #333; word-wrap: break-word; word-break: normal; padding: 0;}.title { font-size: 28px;}.image { width: auto; max-width: auto;}.footer { width: 604px;}.main {}@media screen and (max-device-width: 800px) { .title { font-size: 22px !important; } .image { width: auto !important; max-width: 100% !important; } .footer { width: 100% !important; max-width: 604px !important } .main { width: 100% !important; max-width: 604px !important }} When it's time, join the Webex meeting here. Meeting number (access code): 614 520 039 Meeting password:BWsAF9rT https://ietf.webex.com/ietf/j.php?MTID=m7210004128aa1dba87884a2c0ee806a0"; style="color:#FF; font-size:20px; text-decoration:none;">Join meeting Join by phone Tap to call in from a mobile device (attendees only) 1-650-479-3208 Call-in toll number (US/Canada) Join from a video system or applicationDial 614520...@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join using Microsoft Lync or Microsoft Skype for BusinessDial 614520039.i...@lync.webex.com Need help? Go to http://help.webex.com"; style="color:#049FD9; text-decoration:none;">http://help.webex.com
ATTENDEE;CN="Web Authorization Protocol Working Group";ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO:oauth-cha...@ietf.org
DTSTAMP:20200518T16Z
UID:2045d357-fe78-490a-b904-560dc7ae3602
PRIORITY:5
RECURRENCE-ID;TZID="Europe Time":20200518T18
DTSTART;TZID="Europe Time":20200518T18
DTEND;TZID="Europe Time":20200518T19
SEQUENCE:1589360304
SUMMARY:OAuth WG Virtual Office Hours
TRANSP:OPAQUE
ORGANIZER;CN="Cisco Webex":MAILTO:messen...@webex.com
LOCATION:https://ietf.webex.com/ietf
BEGIN:VALARM
TRIGGER:-PT5M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
