[OAUTH-WG] Canceled Webex meeting: OAuth WG Virtual Office Hours
BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:CANCEL BEGIN:VTIMEZONE TZID:America/New_York LAST-MODIFIED:20221105T024526Z TZURL:https://www.tzurl.org/zoneinfo-outlook/America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZNAME:EDT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 DTSTART:19700308T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZNAME:EST TZOFFSETFROM:-0400 TZOFFSETTO:-0500 DTSTART:19701101T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20241008T131838Z ATTENDEE;CN="oauth@ietf.org";ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO:oauth@ietf.org ORGANIZER;CN="Rifaat Shekh-Yusef":MAILTO:oauth-cha...@ietf.org DTSTART;TZID=America/New_York:20241009T12 DTEND;TZID=America/New_York:20241009T123000 LOCATION:https://ietf.webex.com/ietf TRANSP:OPAQUE SEQUENCE:1728393518 UID:e5c0a906-b5f7-4a49-af60-e405c6e39c2a DESCRIPTION:\n\nThis Webex meeting has been canceled.\n\nTopic: OAuth WG Virtual Office Hours\nDate: Wednesday, October 09, 2024\nTime: 12:00 PM, (UTC-04:00) Eastern Time (US & Canada)\n SUMMARY:OAuth WG Virtual Office Hours PRIORITY:5 CLASS:PUBLIC RECURRENCE-ID;TZID=America/New_York:20241009T12 STATUS:CANCELLED END:VEVENT END:VCALENDAR Webex_meeting.ics Description: Binary data ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Re: Call for adoption - First Party Apps
All, Based on the responses received on the mailing list, we believe that there is enough support for this document to become a WG document. Authors, Feel free to submit a -00 version at your convenience. Regards, Rifaat & Hannes On Tue, Sep 17, 2024 at 4:55 AM Vladimir Dzhuvinov / Connect2id < vladi...@connect2id.com> wrote: > Hi Pieter, > > Thanks for your responses. I'm writing to state my support for the > adoption of this draft. > > I'm starting to see it as a meaningful evolution of the deprecated > password grant. I read the arguments to stay focused on the browser-based > code flow. Browser APIs have evolved over the course of OAuth 2.0, but the > reality is that devs and architects do not see them as ideal in all > situations and the password grant is still being used and considered. This > improved sped for 1st party apps should make it easier to have solutions > that are standard and interoperable. > > About the auth techniques, I would like to ask you and the other authors > working on the spec to consider defining parameters for the ones that are > most likely to see use in practice, in the coming years. I'm asking you > this because my past experience with profiles is that when they do appear, > it may be too late. The JWT profile for access tokens - RFC 9068 - comes to > mind. It was published 9 years after the bearer token RFC. > > Cheers, > > Vladimir > > > On 16/09/2024 16:40, Pieter Kasselman wrote: > > Hi Vladimir > > > > Thanks for reading the draft and raising questions. See responses inline. > > > > Cheers > > > > Pieter > > > > *From:* Vladimir Dzhuvinov / Connect2id > > *Sent:* Friday 13 September 2024 07:50 > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Re: Call for adoption - First Party Apps > > > > I read the proposed spec and it's evident substantial work has gone into > it. Congratulations for this. > > How does the 1st party flow compare to the (deprecated in OAuth 2.1) > password grant? People with existing 1st party apps that rely on the > password grant or consider using it are going to look for a discussion on > this. > > > > The first party flow is meant to provide a framework to allow for multiple > authentication factors to enable MFA type scenarios where there is a first > party trust relationship between the application gathering the credentials > and the authorization server. It provides a pathway from single factor > authentication methods to stronger MFA and ultimately phishing resistant > authentication methods. > > > > > > In terms of security properties (leaving aside the design to support > factors other than user password and the support for interaction), does it > offer advantages? In the simple case (no interaction), do developers have a > reason to choose the 1st party flow when the password grant only needs a > single call to the token endpoint? > > > > The main advantage is the ability to step up to MFA (or even to require a > web redirect to collect credentials on the web if the authorization server > deems the risk of a “first party” flow excessive). > > > > > > The password grant has been subjected to (non-standard) customisations to > support challenges, for example to be able to ask the user for an OTP after > the password is verified. The 1st party flow takes such scenarios into > account, but appears to have taken the framework approach, leaving it up to > developers to complete the definition of the flow for the factors an AS is > required to use / combine. Is it envisioned for the 1st party flow spec to > get complemented with profiles or is it expected developers / deployments > to take care of this? > > > > We expect there will be profiles for popular authentication techniques. > > > > > > Vladimir Dzhuvinov > > On 03/09/2024 13:46, Rifaat Shekh-Yusef wrote: > > All, > > As per the discussion in Vancouver, this is a call for adoption for the > First Party Apps draft: > https://datatracker.ietf.org/doc/draft-parecki-oauth-first-party-apps/ > > Please, reply on the mailing list and let us know if you are in favor or > against adopting this draft as WG document, by *Sep 17th*. > > Regards, > Rifaat & Hannes > > > > ___ > > OAuth mailing list -- oauth@ietf.org > > To unsubscribe send an email to oauth-le...@ietf.org > > ___ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] IETF121 Call for topics
All, This is a call for topics for the coming IETF121 in Dublin. Please, let us know *as soon as possible *if you have topics that you would like to discuss. Regards, Rifaat & Hannes ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Canceled Webex meeting: OAuth WG Virtual Office Hours
BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:CANCEL BEGIN:VTIMEZONE TZID:America/New_York LAST-MODIFIED:20221105T024526Z TZURL:https://www.tzurl.org/zoneinfo-outlook/America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZNAME:EDT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 DTSTART:19700308T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZNAME:EST TZOFFSETFROM:-0400 TZOFFSETTO:-0500 DTSTART:19701101T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20240925T144937Z ATTENDEE;CN="oauth@ietf.org";ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO:oauth@ietf.org ORGANIZER;CN="Rifaat Shekh-Yusef":MAILTO:oauth-cha...@ietf.org DTSTART;TZID=America/New_York:20240925T12 DTEND;TZID=America/New_York:20240925T123000 LOCATION:https://ietf.webex.com/ietf TRANSP:OPAQUE SEQUENCE:1727275777 UID:e5c0a906-b5f7-4a49-af60-e405c6e39c2a DESCRIPTION:\n\nThis Webex meeting has been canceled.\n\nTopic: OAuth WG Virtual Office Hours\nDate: Wednesday, September 25, 2024\nTime: 12:00 PM, (UTC-04:00) Eastern Time (US & Canada)\n SUMMARY:OAuth WG Virtual Office Hours PRIORITY:5 CLASS:PUBLIC RECURRENCE-ID;TZID=America/New_York:20240925T12 STATUS:CANCELLED END:VEVENT END:VCALENDAR Webex_meeting.ics Description: Binary data ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Call for adoption - PIKA
All, As per the discussion in Vancouver, this is a call for adoption for the *Proof of Issuer Key Authority (PIKA) *draft: https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/ Please, reply on the mailing list and let us know if you are in favor or against adopting this draft as WG document, by *Sep 17th*. Regards, Rifaat & Hannes ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Call for adoption - First Party Apps
All, As per the discussion in Vancouver, this is a call for adoption for the First Party Apps draft: https://datatracker.ietf.org/doc/draft-parecki-oauth-first-party-apps/ Please, reply on the mailing list and let us know if you are in favor or against adopting this draft as WG document, by *Sep 17th*. Regards, Rifaat & Hannes ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] WGLC for SD-JWT
All, As per the discussion in Vancouver, this is a WG Last Call for the *SD-JWT * document. https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-11.html Please, review this document and reply on the mailing list if you have any comments or concerns, by *Sep 17th*. Regards, Rifaat & Hannes ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Canceled Webex meeting: OAuth WG Virtual Office Hours
BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:CANCEL BEGIN:VTIMEZONE TZID:America/New_York LAST-MODIFIED:20221105T024526Z TZURL:https://www.tzurl.org/zoneinfo-outlook/America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZNAME:EDT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 DTSTART:19700308T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZNAME:EST TZOFFSETFROM:-0400 TZOFFSETTO:-0500 DTSTART:19701101T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20240827T202658Z ATTENDEE;CN="oauth@ietf.org";ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO:oauth@ietf.org ORGANIZER;CN="Rifaat Shekh-Yusef":MAILTO:oauth-cha...@ietf.org DTSTART;TZID=America/New_York:20240828T12 DTEND;TZID=America/New_York:20240828T123000 LOCATION:https://ietf.webex.com/ietf TRANSP:OPAQUE SEQUENCE:1724790418 UID:e5c0a906-b5f7-4a49-af60-e405c6e39c2a DESCRIPTION:\n\nThis Webex meeting has been canceled.\n\nTopic: OAuth WG Virtual Office Hours\nDate: Wednesday, August 28, 2024\nTime: 12:00 PM, (UTC-04:00) Eastern Time (US & Canada)\n SUMMARY:OAuth WG Virtual Office Hours PRIORITY:5 CLASS:PUBLIC RECURRENCE-ID;TZID=America/New_York:20240828T12 STATUS:CANCELLED END:VEVENT END:VCALENDAR Webex_meeting.ics Description: Binary data ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Canceled Webex meeting: OAuth WG Virtual Office Hours
BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:CANCEL BEGIN:VTIMEZONE TZID:America/New_York LAST-MODIFIED:20221105T024526Z TZURL:https://www.tzurl.org/zoneinfo-outlook/America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZNAME:EDT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 DTSTART:19700308T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZNAME:EST TZOFFSETFROM:-0400 TZOFFSETTO:-0500 DTSTART:19701101T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20240812T150203Z ATTENDEE;CN="oauth@ietf.org";ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO:oauth@ietf.org ORGANIZER;CN="Rifaat Shekh-Yusef":MAILTO:oauth-cha...@ietf.org DTSTART;TZID=America/New_York:20240814T12 DTEND;TZID=America/New_York:20240814T123000 LOCATION:https://ietf.webex.com/ietf TRANSP:OPAQUE SEQUENCE:1723474923 UID:e5c0a906-b5f7-4a49-af60-e405c6e39c2a DESCRIPTION:\n\nThis Webex meeting has been canceled.\n\nTopic: OAuth WG Virtual Office Hours\nDate: Wednesday, August 14, 2024\nTime: 12:00 PM, (UTC-04:00) Eastern Time (US & Canada)\n SUMMARY:OAuth WG Virtual Office Hours PRIORITY:5 CLASS:PUBLIC RECURRENCE-ID;TZID=America/New_York:20240814T12 STATUS:CANCELLED END:VEVENT END:VCALENDAR Webex_meeting.ics Description: Binary data ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Publication has been requested for draft-ietf-oauth-resource-metadata-07
Rifaat Shekh-Yusef has requested publication of draft-ietf-oauth-resource-metadata-07 as Proposed Standard on behalf of the OAUTH working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/ ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Canceled Webex meeting: OAuth WG Virtual Office Hours
BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:CANCEL BEGIN:VTIMEZONE TZID:America/New_York LAST-MODIFIED:20221105T024526Z TZURL:https://www.tzurl.org/zoneinfo-outlook/America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZNAME:EDT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 DTSTART:19700308T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZNAME:EST TZOFFSETFROM:-0400 TZOFFSETTO:-0500 DTSTART:19701101T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20240727T132017Z ATTENDEE;CN="oauth@ietf.org";ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO:oauth@ietf.org ORGANIZER;CN="Rifaat Shekh-Yusef":MAILTO:oauth-cha...@ietf.org DTSTART;TZID=America/New_York:20240731T12 DTEND;TZID=America/New_York:20240731T123000 LOCATION:https://ietf.webex.com/ietf TRANSP:OPAQUE SEQUENCE:1722086417 UID:e5c0a906-b5f7-4a49-af60-e405c6e39c2a DESCRIPTION:\n\nThis Webex meeting has been canceled.\n\nTopic: OAuth WG Virtual Office Hours\nDate: Wednesday, July 31, 2024\nTime: 12:00 PM, (UTC-04:00) Eastern Time (US & Canada)\n SUMMARY:OAuth WG Virtual Office Hours PRIORITY:5 CLASS:PUBLIC RECURRENCE-ID;TZID=America/New_York:20240731T12 STATUS:CANCELLED END:VEVENT END:VCALENDAR Webex_meeting.ics Description: Binary data ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Shepherd write-up for OAuth 2.0 Protected Resource Metadata
All, Here is the shepherd write-up for the OAuth 2.0 Protected Resource Metadata draft: https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/shepherdwriteup/ Please, take a look and let me know if you have any comments. Regards, Rifaat ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] OAuth 2.0 Protected Resource Metadata - IPR Disclosure
Mike, Phil, Aaron, As part of the shepherd write-up, all authors of the OAuth 2.0 Protected Resource Metadata draft must confirm that any and all appropriate *IPR disclosures* required for full conformance with the provisions of BCP 78 and BCP 79 have been disclosed. https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/ Please, reply on the mailing list, and indicate if you are aware of any IPRs associated with this document. Regards, Rifaat ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] OAuth 2.0 Protected Resource Metadata - Implementations
All, As part of the shepherd write-up for the OAuth 2.0 Protected Resource Metadata document, we are looking for information about implementations of this draft. https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-06.html Please, reply on the mailing list with any implementations that you are aware of to support this document. Regards, Rifaat ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Re: Shepherd Review for OAuth 2.0 Protected Resource Metadata draft
All, Mike and I met yesterday and discussed this. My concern was with the potential of a downgrade attack if there is a MITM between the client and the resource server. It seems that the draft defined a protection against such an attack as described in section 3.3. The next step is the shepherd write-up, which I will start soon. Regards, Rifaat On Mon, Jul 8, 2024 at 9:24 AM Michael Jones wrote: > Can you reply to this today, Rifaat? > > Thanks, > -- Mike > > > -- > *From:* Michael Jones > *Sent:* Saturday, July 6, 2024 12:55:19 PM > *To:* Rifaat Shekh-Yusef > *Cc:* oauth > *Subject:* RE: [OAUTH-WG] Shepherd Review for OAuth 2.0 Protected > Resource Metadata draft > > > What puzzles me of talking about downgrade attacks in this context is > between what points in time you are anticipating that a downgrade might > occur. The Resource Server advertises its proposed authentication methods > in a WWW-Authenticate response. The client then chooses one of them, > probably within milliseconds of receiving the WWW-Authenticate response. > When in that flow are you thinking that a downgrade might occur? > > > > Remember that the client is essentially instantaneously using fresh > information provided by the resource server. It is not using information > provided at some prior time. > > > > If not the text already proposed in the PR, what specifically would you > suggest that we say about downgrade possibilities? > > > > -- Mike > > > > *From:* Rifaat Shekh-Yusef > *Sent:* Saturday, July 6, 2024 5:05 AM > *To:* Michael Jones > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] Shepherd Review for OAuth 2.0 Protected > Resource Metadata draft > > > > > > A fair question is whether allowing clients to choose from among > supported authentication methods represents an opportunity for a > downgrade attack. > Since resource servers will only enumerate authentication methods > acceptable to them, by definition, > any choice made by the client from among them is one that the resource > server is OK with. > Thus, the resource server allowing the use of different supported > authentication methods > does not represent an opportunity for a downgrade attack. > > > > A resource server could be configured to accept a method that is > considered secure at one time, that might be considered insecure later on. > > A resource server could also be misconfigured with insecure methods. > > > > For this reason, I still think that a discussion of a potential downgrade > attack is warranted in the security consideration section. > > > > Regards, > > Rifaat > > > > > > > > > > > > On Sat, Jul 6, 2024 at 12:30 AM Michael Jones > wrote: > > The PR > https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/pull/45 is > intended to address these shepherd review comments. Please review. > > > > Thanks, > > -- Mike > > > > *From:* Rifaat Shekh-Yusef > *Sent:* Thursday, July 4, 2024 5:30 AM > *To:* oauth > *Subject:* [OAUTH-WG] Shepherd Review for OAuth 2.0 Protected Resource > Metadata draft > > > > Mike, Phil, Aaron, > > > > The following is my shepherd review for OAuth 2.0 Protected Resource > Metadata > https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-05.html > > *Comments/Questions* > > 5.4. Compatibility with other authentication methods > > Would this not open the door for potential downgrade attacks if the list > of authentication methods include weaker methods? > I think this should be discussed in the Security Consideration section. > > > *Nits* > > Section 1, second sentence: > “This specification is intentionally as parallel as possible …” > It feels like there is a missing word after “intentionally”; maybe > “designed”, “specified”? > > Regards, > > Rifaat > > > > ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] OAuth WG @ IETF120 - Draft Agenda
All, Here is our draft agenda for our 3 OAuth sessions at IETF120: https://datatracker.ietf.org/doc/agenda-120-oauth/ Please, take a look and let us know what you think. Regards, Rifaat & Hannes ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Re: Shepherd Review for OAuth 2.0 Protected Resource Metadata draft
> A fair question is whether allowing clients to choose from among > supported authentication methods represents an opportunity for a > downgrade attack. > Since resource servers will only enumerate authentication methods > acceptable to them, by definition, > any choice made by the client from among them is one that the resource > server is OK with. > Thus, the resource server allowing the use of different supported > authentication methods > does not represent an opportunity for a downgrade attack. > A resource server could be configured to accept a method that is considered secure at one time, that might be considered insecure later on. A resource server could also be misconfigured with insecure methods. For this reason, I still think that a discussion of a potential downgrade attack is warranted in the security consideration section. Regards, Rifaat On Sat, Jul 6, 2024 at 12:30 AM Michael Jones wrote: > The PR > https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/pull/45 is > intended to address these shepherd review comments. Please review. > > > > Thanks, > > -- Mike > > > > *From:* Rifaat Shekh-Yusef > *Sent:* Thursday, July 4, 2024 5:30 AM > *To:* oauth > *Subject:* [OAUTH-WG] Shepherd Review for OAuth 2.0 Protected Resource > Metadata draft > > > > Mike, Phil, Aaron, > > > > The following is my shepherd review for OAuth 2.0 Protected Resource > Metadata > https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-05.html > > *Comments/Questions* > > 5.4. Compatibility with other authentication methods > > Would this not open the door for potential downgrade attacks if the list > of authentication methods include weaker methods? > I think this should be discussed in the Security Consideration section. > > > *Nits* > > Section 1, second sentence: > “This specification is intentionally as parallel as possible …” > It feels like there is a missing word after “intentionally”; maybe > “designed”, “specified”? > > Regards, > > Rifaat > > > ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Shepherd Review for OAuth 2.0 Protected Resource Metadata draft
Mike, Phil, Aaron, The following is my shepherd review for OAuth 2.0 Protected Resource Metadata https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-05.html *Comments/Questions* 5.4. Compatibility with other authentication methods Would this not open the door for potential downgrade attacks if the list of authentication methods include weaker methods? I think this should be discussed in the Security Consideration section. *Nits* Section 1, second sentence: “This specification is intentionally as parallel as possible …” It feels like there is a missing word after “intentionally”; maybe “designed”, “specified”? Regards, Rifaat ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Fwd: Webex meeting canceled: OAuth WG Virtual Office Hours
Sorry, I need to cancel this meeting for today. Regards, Rifaat -- Forwarded message - From: Rifaat Shekh-Yusef Date: Wed, Jun 19, 2024 at 11:35 AM Subject: Webex meeting canceled: OAuth WG Virtual Office Hours To: You canceled this Webex meeting. Wednesday, June 19, 2024 12:00 PM | (UTC-04:00) Eastern Time (US & Canada) | 30 mins Need help? Go to https://help.webex.com invite.ics Description: application/ics Webex_meeting.ics Description: application/ics ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Canceled Webex meeting: OAuth WG Virtual Office Hours
BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:CANCEL BEGIN:VTIMEZONE TZID:America/New_York LAST-MODIFIED:20221105T024526Z TZURL:https://www.tzurl.org/zoneinfo-outlook/America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZNAME:EDT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 DTSTART:19700308T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZNAME:EST TZOFFSETFROM:-0400 TZOFFSETTO:-0500 DTSTART:19701101T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20240619T153548Z ATTENDEE;CN="oauth@ietf.org";ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO:oauth@ietf.org ORGANIZER;CN="Rifaat Shekh-Yusef":MAILTO:oauth-cha...@ietf.org DTSTART;TZID=America/New_York:20240619T12 DTEND;TZID=America/New_York:20240619T123000 LOCATION:https://ietf.webex.com/ietf TRANSP:OPAQUE SEQUENCE:1718811348 UID:e5c0a906-b5f7-4a49-af60-e405c6e39c2a DESCRIPTION:\n\nThis Webex meeting has been canceled.\n\nTopic: OAuth WG Virtual Office Hours\nDate: Wednesday, June 19, 2024\nTime: 12:00 PM, (UTC-04:00) Eastern Time (US & Canada)\n SUMMARY:OAuth WG Virtual Office Hours PRIORITY:5 CLASS:PUBLIC RECURRENCE-ID;TZID=America/New_York:20240619T12 STATUS:CANCELLED END:VEVENT END:VCALENDAR Webex_meeting.ics Description: Binary data ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Re: [ID-align] Re: Re: Re: Fwd: Internet Terminology Glossary
On Mon, Jun 17, 2024 at 4:49 PM Dick Hardt wrote:
> ( OAuth is in the cc cuz Rifaat :)
>
> Guilty as charged :)
Regards,
Rifaat
The objective is to reduce confusion in standards development by gathering
> the definitions for terms used in existing specifications, and to create
> awareness of the existing definitions for new work so that existing
> definitions are used, or new definitions are intentionally created.
>
> So yes, documents with new terms, and new definitions for existing terms
> would be referenced in the glossary.
>
> On Sat, Jun 15, 2024 at 9:23 AM Michael Richardson
> wrote:
>
>>
>> {does oauth need to remain in the CC?}
>>
>> Rifaat Shekh-Yusef wrote:
>> > The *draft* proposal is talking about a *live* document, with some
>> > ideas borrowed from the IANA registry process.
>>
>> Hmm... registration process.
>> It sounds like you are maybe thinking _Specification Required_?
>>
>> So would documents that introduce new terms then be referenced from the
>> Glossary?
>> I kind of like that, but I also think it might be too restrictive if
>> that's
>> the only way to add to it. But, perhaps different entries have different
>> levels of authority, and a term that comes from a Specification gets a
>> higher
>> status.
>>
>> In general, I think about the many (often vastly different) definitions
>> that
>> one can see in, for instance, the urban dictionary (.com).
>>
>> --
>> Michael Richardson. o O ( IPv6 IøT consulting
>> )
>>Sandelman Software Works Inc, Ottawa and Worldwide
>>
>>
>>
>>
>> ___
>> OAuth mailing list -- oauth@ietf.org
>> To unsubscribe send an email to oauth-le...@ietf.org
>>
> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Re: [ID-align] Re: Fwd: Internet Terminology Glossary
Thanks Denis! This is very helpful. On Thu, Jun 13, 2024 at 3:24 PM Denis wrote: > Hi Rifaat, > > FYI, I copy and paste a part of a message I sent to saag on 14/03/2024. > > *Every RFC shall include a "Terms and definitions" section for the > vocabulary that it uses* > > This topic is rather for the IESG, but could be reported to the IESG > by the SEC ADs. > > Every ISO standard must include a Clause 3 that defines the terms and > the definitions that are used. > This has a merit: different ISO standards can use the same terms with > a different meaning when necessary. > ISO provides a (free) nice tool to find ALL the definitions of a term > in ALL the *published * ISO documents: https://www.iso.org/obp/ui > This is a great help when there is the need to define a new term, and > in some cases to avoid to reinvent the wheel. > > Note: within ISO, a definition is a single sentence and no more. > > Currently, the IETF does not mandate RFCs to include a "Terms and > definitions" section. This should evolve. > > On the long term, it would be nice to have a resource like: > https://www.ietf.org/obp/ui > > Denis > > I think we are in agreement here. > I did not mean for "dynamic" to be interpreted as the term might change > after it was defined. > I will try to avoid using the term "dynamic" to avoid any future confusion. > > Regards, > Rifaat > > > > On Thu, Jun 13, 2024 at 3:10 PM Michael Richardson > wrote: > >> >> Rifaat Shekh-Yusef wrote: >> > That's where we started, but that was deemed problematic because >> that >> > document was produced as an Independent Submission Stream, which is >> > outside of the IETF process. Also, the RFC is a static document, >> while >> > what we are proposing is a living and dynamic document. >> >> I think that we can update/replace 4949. The fact that it came through >> ISE >> doesn't matter: we can produce a new document. >> >> While I agree that we need a living document which is easy to extend and >> amend, I don't actually think we want "dynamic". Having the definition of >> terms change from under the users of the term is a problem. >> >> So I am in agreement that a git backed wiki is a good way to build a >> terminology, I think that the contents should be fixed periodically so >> that >> it can be stably referenced. That doesn't mean it has to be an RFC; many >> wiki have the ability to reference a term at a specific date. >> >> ps: thank you for championing this, it's way overdue. >> >> -- >> Michael Richardson. o O ( IPv6 IøT consulting >> ) >>Sandelman Software Works Inc, Ottawa and Worldwide >> >> >> >> >> -- >> ID-align mailing list -- id-al...@ietf.org >> To unsubscribe send an email to id-align-le...@ietf.org >> > > ___ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > > > ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Re: [ID-align] Re: Fwd: Internet Terminology Glossary
** living document*. On Thu, Jun 13, 2024 at 4:22 PM Rifaat Shekh-Yusef wrote: > Adding the id-align list to the thread. > > The *draft* proposal is talking about a *live* document, with some ideas > borrowed from the IANA registry process. > We are sharing this here to get the community's thoughts on this, so we > would together come up with a proper process for such a document. > > Regards, > Rifaat > > > > > > On Thu, Jun 13, 2024 at 4:12 PM Carsten Bormann wrote: > >> On 2024-06-13, at 22:02, Dick Hardt wrote: >> > >> > ISO has its processes and IETF has its processes >> >> Right. >> >> We don’t have a process for living documents. >> >> (We do have processes for IANA registries, which could be misused here. >> Maybe that is actually what you are trying to do here. I’d love to be >> Designated Expert on that registry :-) >> >> Grüße, Carsten >> >> >> ___ >> OAuth mailing list -- oauth@ietf.org >> To unsubscribe send an email to oauth-le...@ietf.org >> > ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Re: [ID-align] Re: Fwd: Internet Terminology Glossary
Adding the id-align list to the thread. The *draft* proposal is talking about a *live* document, with some ideas borrowed from the IANA registry process. We are sharing this here to get the community's thoughts on this, so we would together come up with a proper process for such a document. Regards, Rifaat On Thu, Jun 13, 2024 at 4:12 PM Carsten Bormann wrote: > On 2024-06-13, at 22:02, Dick Hardt wrote: > > > > ISO has its processes and IETF has its processes > > Right. > > We don’t have a process for living documents. > > (We do have processes for IANA registries, which could be misused here. > Maybe that is actually what you are trying to do here. I’d love to be > Designated Expert on that registry :-) > > Grüße, Carsten > > > ___ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Re: Fwd: Internet Terminology Glossary
That's where we started, but that was deemed problematic because that document was produced as an Independent Submission Stream, which is outside of the IETF process. Also, the RFC is a static document, while what we are proposing is a living and dynamic document. Regards, Rifaat On Thu, Jun 13, 2024 at 12:51 PM Michael Jones wrote: > Is this intended to replace https://www.rfc-editor.org/rfc/rfc4949.html? > > > > *From:* Rifaat Shekh-Yusef > *Sent:* Thursday, June 13, 2024 9:14 AM > *To:* oauth > *Subject:* [OAUTH-WG] Fwd: Internet Terminology Glossary > > > > > > ------ Forwarded message - > From: *Rifaat Shekh-Yusef* > Date: Thu, Jun 13, 2024 at 11:38 AM > Subject: Internet Terminology Glossary > To: > > > > All, > > > > Dick and I put together the following *draft* proposal for an *Internet > Terminology Glossary*: > > https://github.com/dickhardt/glossary/blob/main/glossary.md > > > > We discussed this with a few members of the IETF RFC Editor team and IETF > executives. > > Dick and I are planning on presenting and discussing this at the SAAG WG > meeting during the coming IETF conference in Vancouver. > > > > Please, review this draft proposal and provide your feedback on the > mailing list. > > A call will be scheduled to discuss this on *Friday, June 21st at 12:00pm > ET.* > > > > Regards, > > Rifaat & Dick > > > > > > > ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Re: Fwd: Internet Terminology Glossary
A BCP is not a living document. We do not want to publish a new RFC every time there is a new term defined somewhere. On Thu, Jun 13, 2024 at 1:50 PM Michael Jones wrote: > If you want a dynamic document, you could create a BCP. And the RFC could > indicate that it obsoletes RFC 4949. > > > > *From:* Rifaat Shekh-Yusef > *Sent:* Thursday, June 13, 2024 10:34 AM > *To:* Michael Jones > *Cc:* oauth ; id-al...@ietf.org > *Subject:* Re: [OAUTH-WG] Fwd: Internet Terminology Glossary > > > > That's where we started, but that was deemed problematic because that > document was produced as an Independent Submission Stream, which is outside > of the IETF process. > > Also, the RFC is a static document, while what we are proposing is a > living and dynamic document. > > > > Regards, > > Rifaat > > > > > > On Thu, Jun 13, 2024 at 12:51 PM Michael Jones < > michael_b_jo...@hotmail.com> wrote: > > Is this intended to replace https://www.rfc-editor.org/rfc/rfc4949.html? > > > > *From:* Rifaat Shekh-Yusef > *Sent:* Thursday, June 13, 2024 9:14 AM > *To:* oauth > *Subject:* [OAUTH-WG] Fwd: Internet Terminology Glossary > > > > > > -- Forwarded message - > From: *Rifaat Shekh-Yusef* > Date: Thu, Jun 13, 2024 at 11:38 AM > Subject: Internet Terminology Glossary > To: > > > > All, > > > > Dick and I put together the following *draft* proposal for an *Internet > Terminology Glossary*: > > https://github.com/dickhardt/glossary/blob/main/glossary.md > > > > We discussed this with a few members of the IETF RFC Editor team and IETF > executives. > > Dick and I are planning on presenting and discussing this at the SAAG WG > meeting during the coming IETF conference in Vancouver. > > > > Please, review this draft proposal and provide your feedback on the > mailing list. > > A call will be scheduled to discuss this on *Friday, June 21st at 12:00pm > ET.* > > > > Regards, > > Rifaat & Dick > > > > > > > > ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Re: [ID-align] Re: Fwd: Internet Terminology Glossary
I think we are in agreement here. I did not mean for "dynamic" to be interpreted as the term might change after it was defined. I will try to avoid using the term "dynamic" to avoid any future confusion. Regards, Rifaat On Thu, Jun 13, 2024 at 3:10 PM Michael Richardson wrote: > > Rifaat Shekh-Yusef wrote: > > That's where we started, but that was deemed problematic because that > > document was produced as an Independent Submission Stream, which is > > outside of the IETF process. Also, the RFC is a static document, > while > > what we are proposing is a living and dynamic document. > > I think that we can update/replace 4949. The fact that it came through ISE > doesn't matter: we can produce a new document. > > While I agree that we need a living document which is easy to extend and > amend, I don't actually think we want "dynamic". Having the definition of > terms change from under the users of the term is a problem. > > So I am in agreement that a git backed wiki is a good way to build a > terminology, I think that the contents should be fixed periodically so that > it can be stably referenced. That doesn't mean it has to be an RFC; many > wiki have the ability to reference a term at a specific date. > > ps: thank you for championing this, it's way overdue. > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > > > -- > ID-align mailing list -- id-al...@ietf.org > To unsubscribe send an email to id-align-le...@ietf.org > ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Fwd: Internet Terminology Glossary
-- Forwarded message - From: Rifaat Shekh-Yusef Date: Thu, Jun 13, 2024 at 11:38 AM Subject: Internet Terminology Glossary To: All, Dick and I put together the following *draft* proposal for an *Internet Terminology Glossary*: https://github.com/dickhardt/glossary/blob/main/glossary.md We discussed this with a few members of the IETF RFC Editor team and IETF executives. Dick and I are planning on presenting and discussing this at the SAAG WG meeting during the coming IETF conference in Vancouver. Please, review this draft proposal and provide your feedback on the mailing list. A call will be scheduled to discuss this on *Friday, June 21st at 12:00pm ET.* Regards, Rifaat & Dick ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Fwd: Help with call for volunteers
Please, consider volunteering for 2024 NomCom to help with selecting the next round of IETF leaders. Regards, Rifaat --- The IETF tools development team identified an error in the interface between the IETF registration system and the datatracker that mistakenly marked people as volunteers for the 2024 NomCom. (Please note that volunteering via the registration system is not offered for IETF 120 registration.) This error was corrected, and the fix was deployed on June 4. The correction for the bug can be viewed at https://github.com/ietf-tools/datatracker/pull/7484. We have removed the incorrect volunteer records as of June 5. However, this has led to a severely reduced number of eligible volunteers. Please review your status and consider volunteering for NomCom 2024-2025. Please check your status at https://datatracker.ietf.org/accounts/profile/ after signing in under the "NomCom Eligible" section,. If you have already explicitly volunteered using the datatracker, you will see "You have volunteered for the Nominating Committee 2024/2025.” If you are not yet volunteered, you will see a Volunteer button. You can also volunteer via CLICK HERE TO VOLUNTEER: https://datatracker.ietf.org/nomcom/volunteer or directly emailing Dean Bogdanovic at nomcom-chair-2...@ietf.org Thanks to everyone who has volunteered so far. However, we currently have only eligible 100 volunteers. We need many more. So, please, please volunteer. Dean Bogdanovic nomcom-chair-2...@ietf.org ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Call for adoption - PIKA
All, This is an official call for adoption for the *Proof of Issuer Key Authority (PIKA)* draft: https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/ Please, reply *on the mailing list* and let us know if you are in favor or against adopting this draft as WG document, by *June 24th*. Regards, Rifaat & Hannes ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Fwd: [Tools-discuss] Update on ongoing mail delivery issues
-- Forwarded message - From: Robert Sparks Date: Tue, May 21, 2024 at 4:26 PM Subject: [Tools-discuss] Update on ongoing mail delivery issues To: tools-discuss , Working Chairs < wgcha...@ietf.org>, If you have had a message fail to deliver to a list since the mailman3 transition, please resend it at this time. If it fails to deliver again, please let us know by sending the message-id to tools-h...@ietf.org. Several improvements were made yesterday and this morning that further reduce the number of messages that are not delivered to lists, even though they appear to have been accepted. More improvements are expected later today. We are down to a small percentage of messages failing to deliver. However, we are not confident that all delivery issues will be resolved today. Work on delivering the messages that were accepted but not yet delivered has started. It is expected to take several days to complete. This turns out to be surprisingly complex. It is possible that they won't be recoverable. There is a fallback plan (involving reverting to mailman2) should addressing these remaining delivery issues take more than a few days, but we currently don't expect to need to use it. RjS --- Tools-discuss mailing list -- tools-disc...@ietf.org To unsubscribe send an email to tools-discuss-le...@ietf.org https://mailarchive.ietf.org/arch/browse/tools-discuss/ ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Re: Canceled Webex meeting: OAuth WG Virtual Office Hours
Please, ignore this email. As a result of the recent migration to mailman3, some messages sent to the list a few weeks back did not go through, and are being released now. We will hold the OAuth WG Virtual Office Hours meeting this week. Regards, Rifaat On Tue, May 21, 2024 at 2:28 PM Rifaat Shekh-Yusef wrote: > > > Rifaat Shekh-Yusef canceled this Webex meeting. > > Wednesday, May 08, 2024 > 12:00 PM | (UTC-04:00) Eastern Time (US & Canada) | 30 mins > > Need help? Go to https://help.webex.com > > ___ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Re: Webex meeting canceled: OAuth WG Virtual Office Hours
I have a conflict this week and will not be able to host this meeting. Regards, Rifaat On Tue, May 7, 2024 at 3:36 PM Rifaat Shekh-Yusef wrote: > > > You canceled this Webex meeting. > > Wednesday, May 08, 2024 > 12:00 PM | (UTC-04:00) Eastern Time (US & Canada) | 30 mins > > Need help? Go to https://help.webex.com > > ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Canceled Webex meeting: OAuth WG Virtual Office Hours
BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:CANCEL BEGIN:VTIMEZONE TZID:America/New_York LAST-MODIFIED:20221105T024526Z TZURL:https://www.tzurl.org/zoneinfo-outlook/America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZNAME:EDT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 DTSTART:19700308T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZNAME:EST TZOFFSETFROM:-0400 TZOFFSETTO:-0500 DTSTART:19701101T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20240507T193638Z ATTENDEE;CN="oauth@ietf.org";ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO:oauth@ietf.org ORGANIZER;CN="Rifaat Shekh-Yusef":MAILTO:oauth-cha...@ietf.org DTSTART;TZID=America/New_York:20240508T12 DTEND;TZID=America/New_York:20240508T123000 LOCATION:https://ietf.webex.com/ietf TRANSP:OPAQUE SEQUENCE:1715110598 UID:e5c0a906-b5f7-4a49-af60-e405c6e39c2a DESCRIPTION:\n\nThis Webex meeting has been canceled.\n\nTopic: OAuth WG Virtual Office Hours\nDate: Wednesday, May 08, 2024\nTime: 12:00 PM, (UTC-04:00) Eastern Time (US & Canada)\n SUMMARY:OAuth WG Virtual Office Hours PRIORITY:5 CLASS:PUBLIC RECURRENCE-ID;TZID=America/New_York:20240508T12 STATUS:CANCELLED END:VEVENT END:VCALENDAR Webex_meeting.ics Description: Binary data ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Second WGLC for OAuth 2.0 Protected Resource Metadata
All, This is a *second* *WG Last Call* for the *OAuth 2.0 Protected Resource Metadata* document (the previous one was for v03.). https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-05.html Please, review this document and reply on the mailing list if you have any comments or concerns, by *May 29*. If you reviewed the document and you do not have any comments or concerns, it would be great if you can reply to this email indicating that. Regards, Rifaat & Hannes ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Re: [lamps] Revocation and OAuth
Adding the OAuth WG to this thread. Regards, Rifaat On Wed, May 15, 2024 at 7:52 AM Carl Wallace wrote: > Here're a few questions/comments from a first read of > draft-ietf-oauth-status-list. Overall, the approach looks good to me. > > > > Should at least one of ttl and exp be required? Why is ttl not listed for > CBOR? Are both mechanisms needed? > > > > It mahy be worth including some words on using the uri field to partition > status lists based on token lifetime so status lists don't linger. The uri > field is similar to partitioning using the IDP/CDP mechanism in CRLs, so > any partitioning scheme could work, but mentioning the concept may be > helpful. > > > > Should there be a POST option for requesting a status list that provides > for freshness via a nonce? If so, does this cause a need for delegation so > a token signing key need not be online (i.e., maybe some identifier in the > status claim in the referenced token)? This would make GET requests > analogous to partitioned CRLs and POST requests analogous to OCSP with a > nonce, with the extra benefit that both use the same format. > > > > The mechanism is simple, which is good, but the lack of a time value > corresponding to revocation time may limit applicability. If JWTs/CWTs > replace certificates where signature validation is well after generation, > is a revocation mechanism needed that supports similar support for grace > periods, verification relative to times in the past, etc? It may be worth > noting cases where this mechanism may not be a good fit for such use cases > even if not addressing. A POST request that accepted a time value may serve > this purpose with no change to the status list definition, i.e., just > return the response relative to the requested time instead of current. > > > > *From: *Spasm on behalf of "Tschofenig, Hannes" > > *Date: *Friday, May 3, 2024 at 3:28 AM > *To: *"sp...@ietf.org" > *Cc: *Rifaat Shekh-Yusef > *Subject: *[lamps] Revocation and OAuth > > > > Hi all, > > > > At the last two IETF meetings I mentioned that the OAuth working group is > looking into various “token” revocation mechanisms and there is a strong > similarity with the work done in the PKIX environment. See also my HotRFC > presentation at IETF118: Can we improve certificate/JWT/CWT revocation? > (ietf.org) > <https://datatracker.ietf.org/meeting/118/materials/slides-118-hotrfc-sessa-can-we-improve-certificatejwtcwt-revocation-00> > > > > Rifaat and I want to make sure that we take the experience from LAMPS into > account. Hence, we have scheduled a dedicated interim meeting on the topic > of revocation, see > > [OAUTH-WG] Invitation: OAuth WG Virtual Interim - Revocation Drafts @ Tue > Jun 11, 2024 12pm - 1pm (EDT) (oauth@ietf.org) > > > > It would be great if some of you could join the interim meeting. > > > > Ciao > Hannes > > > > ___ Spasm mailing list > sp...@ietf.org https://www.ietf.org/mailman/listinfo/spasm > ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Fwd: [Tools-discuss] Update on ongoing mail delivery issues and request to resend failed messages
-- Forwarded message - From: Robert Sparks Date: Thu, May 9, 2024 at 3:29 PM Subject: [Tools-discuss] Update on ongoing mail delivery issues and request to resend failed messages To: tools-discuss , Working Chairs < wgcha...@ietf.org>, If you have had a message fail to deliver to a list since the mailman3 transition, please resend it at this time. If it fails to deliver again, please let us know by sending the message-id to tools-h...@ietf.org. There was a period today (roughly 1600-1900 UTC) where no messages made it through to the lists. The issue that led to that, and many earlier failures has been addressed. Several other improvements were made yesterday and this morning that further reduced the number of messages that were not delivered to lists, even though they appeared to have been accepted. We are hopeful, but not yet confident, that all delivery issues have now been addressed. The system continues to be monitored by several people for signs of ongoing issues. Work on delivering the messages that were accepted but not yet delivered has started. It is expected to take several days to complete. This turns out to be surprisingly complex. It is possible that they won't be recoverable. RjS --- Tools-discuss mailing list -- tools-disc...@ietf.org To unsubscribe send an email to tools-discuss-le...@ietf.org https://mailarchive.ietf.org/arch/browse/tools-discuss/ ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] WGLC for Browser-Based Apps
All, This is a *WG Last Call* for the *Browser-Based Apps* draft. https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ Please, review this document and reply on the mailing list if you have any comments or concerns, by *May 15. * If you reviewed the document and you do not have any comments or concerns, it would be great if you can reply to this email indicating that. Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Invitation: OAuth WG Virtual Interim - Revocation Drafts @ Tue Jun 11, 2024 12pm - 1pm (EDT) (oauth@ietf.org)
BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/Toronto X-LIC-LOCATION:America/Toronto BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:19700308T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:19701101T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTART;TZID=America/Toronto:20240611T12 DTEND;TZID=America/Toronto:20240611T13 DTSTAMP:20240429T153530Z ORGANIZER;CN=Rifaat Shekh-Yusef:mailto:rifaat.s.i...@gmail.com UID:5bqme8k6pme30bc7i9r5aap...@google.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE ;CN=Rifaat Shekh-Yusef;X-NUM-GUESTS=0:mailto:rifaat.s.i...@gmail.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=oauth@ietf.org;X-NUM-GUESTS=0:mailto:oauth@ietf.org X-MICROSOFT-CDO-OWNERAPPTID:119925306 CREATED:20240429T153528Z DESCRIPTION:The Web Authorization Protocol (oauth) WG will hold a virtual i nterim meetingon 2024-06-11 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC).Agenda:Token Status Listhttps://data tracker.ietf.org/doc/draft-ietf-oauth-status-list/" target="_blank">https:/ /datatracker.ietf.org/doc/draft-ietf-oauth-status-list/OAuth Status Attestationhttps://datatracker.ietf.org/doc /draft-demarco-oauth-status-attestations/" target="_blank">https://datatrac ker.ietf.org/doc/draft-demarco-oauth-status-attestations/ Global Token Revocationhttps://datatracker.ietf.org/do c/draft-parecki-oauth-global-token-revocation/" target="_blank">https://dat atracker.ietf.org/doc/draft-parecki-oauth-global-token-revoca tion/Information about remote participation:https://meetings.conf.meetecho.com/interi m/?group=79913841-6dcc-4d63-a1f4-26484e75fee9--< br>A calendar subscription for all oauth meetings is available athttps://datatracker.ietf.org/meeting/upcoming.ics?show=oauth"; target="_b lank">https://datatracker.ietf.org/meeting/upcoming.ics?show=oauth LAST-MODIFIED:20240429T153528Z LOCATION: SEQUENCE:0 STATUS:CONFIRMED SUMMARY:OAuth WG Virtual Interim - Revocation Drafts TRANSP:OPAQUE BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:This is an event reminder TRIGGER:-P0DT0H30M0S END:VALARM END:VEVENT END:VCALENDAR invite.ics Description: application/ics ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Invitation: OAuth WG Virtual Interim - PIKA @ Tue Jun 4, 2024 12pm - 1pm (EDT) (oauth@ietf.org)
BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/Toronto X-LIC-LOCATION:America/Toronto BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:19700308T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:19701101T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTART;TZID=America/Toronto:20240604T12 DTEND;TZID=America/Toronto:20240604T13 DTSTAMP:20240429T153424Z ORGANIZER;CN=Rifaat Shekh-Yusef:mailto:rifaat.s.i...@gmail.com UID:64c4p681gag1afcpspj48b0...@google.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE ;CN=Rifaat Shekh-Yusef;X-NUM-GUESTS=0:mailto:rifaat.s.i...@gmail.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=oauth@ietf.org;X-NUM-GUESTS=0:mailto:oauth@ietf.org X-MICROSOFT-CDO-OWNERAPPTID:-1427999296 CREATED:20240429T153423Z DESCRIPTION:The Web Authorization Protocol (oauth) WG will hold a virtual i nterim meetingon 2024-06-04 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC).Agenda:PIKAhttps://datatracker.ietf. org/doc/draft-barnes-oauth-pika/" target="_blank">https://datatracker.ietf. org/doc/draft-barnes-oauth-pika/Information about re mote participation:https://meetings.conf.meetecho.com/interim/ ?group=03b19043-f521-420a-ac64-cbf2fea024b2" target="_blank">https://meetin gs.conf.meetecho.com/interim/?group=03b19043-f521-420a-ac64-c bf2fea024b2--A calendar subscription for all oauth meetings is available athttps://datatracker.ietf.org/meeting/u pcoming.ics?show=oauth" target="_blank">https://datatracker.ietf.org/meeting/upcoming.ics?show=oauth LAST-MODIFIED:20240429T153423Z LOCATION: SEQUENCE:0 STATUS:CONFIRMED SUMMARY:OAuth WG Virtual Interim - PIKA TRANSP:OPAQUE BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:This is an event reminder TRIGGER:-P0DT0H30M0S END:VALARM END:VEVENT END:VCALENDAR invite.ics Description: application/ics ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Invitation: OAuth WG Virtual Interim - Attestation-Based Client Authe... @ Tue May 21, 2024 12pm - 1pm (EDT) (oauth@ietf.org)
BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/Toronto X-LIC-LOCATION:America/Toronto BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:19700308T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:19701101T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTART;TZID=America/Toronto:20240521T12 DTEND;TZID=America/Toronto:20240521T13 DTSTAMP:20240429T153311Z ORGANIZER;CN=Rifaat Shekh-Yusef:mailto:rifaat.s.i...@gmail.com UID:4m80v6995aubre076s18s6b...@google.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE ;CN=Rifaat Shekh-Yusef;X-NUM-GUESTS=0:mailto:rifaat.s.i...@gmail.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=oauth@ietf.org;X-NUM-GUESTS=0:mailto:oauth@ietf.org X-MICROSOFT-CDO-OWNERAPPTID:-797387701 CREATED:20240429T153310Z DESCRIPTION:The Web Authorization Protocol (oauth) WG will hold a virtual i nterim meetingon 2024-05-21 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC).Agenda:Attestation-Based Client Authenticationhttps://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-bas ed-client-auth/" target="_blank">https://datatracker.ietf.org/doc/dr aft-ietf-oauth-attestation-based-client-auth/Informa tion about remote participation:https://meetings.conf.meetecho .com/interim/?group=1eb12272-f75f-4624-8eb1-fd805476fc1f" target="_blank">h ttps://meetings.conf.meetecho.com/interim/?group=1eb12272-f75 f-4624-8eb1-fd805476fc1f--A calendar subscription f or all oauth meetings is available athttps://datatracker.ietf. org/meeting/upcoming.ics?show=oauth" target="_blank">https://datatracker.ie tf.org/meeting/upcoming.ics?show=oauth LAST-MODIFIED:20240429T153310Z LOCATION: SEQUENCE:0 STATUS:CONFIRMED SUMMARY:OAuth WG Virtual Interim - Attestation-Based Client Authentication TRANSP:OPAQUE BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:This is an event reminder TRIGGER:-P0DT0H30M0S END:VALARM END:VEVENT END:VCALENDAR invite.ics Description: application/ics ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Invitation: OAuth WG Virtual Interim - OAuth 2.1 @ Tue May 14, 2024 12pm - 1pm (EDT) (oauth@ietf.org)
BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/Toronto X-LIC-LOCATION:America/Toronto BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:19700308T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:19701101T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTART;TZID=America/Toronto:20240514T12 DTEND;TZID=America/Toronto:20240514T13 DTSTAMP:20240429T153202Z ORGANIZER;CN=Rifaat Shekh-Yusef:mailto:rifaat.s.i...@gmail.com UID:41beum7datse934jnn861sp...@google.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE ;CN=Rifaat Shekh-Yusef;X-NUM-GUESTS=0:mailto:rifaat.s.i...@gmail.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=oauth@ietf.org;X-NUM-GUESTS=0:mailto:oauth@ietf.org X-GOOGLE-CONFERENCE:https://meet.google.com/usn-iqyu-tgg X-MICROSOFT-CDO-OWNERAPPTID:1261905907 CREATED:20240429T153200Z DESCRIPTION:The Web Authorization Protocol (oauth) WG will hold a virtual i nterim meetingon 2024-05-14 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC).Agenda:OAuth 2.1https://datatracker. ietf.org/doc/draft-ietf-oauth-v2-1/" target="_blank">https://datatracker.ie tf.org/doc/draft-ietf-oauth-v2-1/Information about r emote participation:https://meetings.conf.meetecho.com/interim /?group=b63a1949-66b2-400d-8b7e-7e10e8598495" target="_blank">https://meeti ngs.conf.meetecho.com/interim/?group=b63a1949-66b2-400d-8b7e- 7e10e8598495--A calendar subscription for all oauth meetings is available athttps://datatracker.ietf.org/meeting/ upcoming.ics?show=oauth" target="_blank">https://datatracker.ietf.org/meeting/upcoming.ics?show=oauth\n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~: ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nJoin with Google Mee t: https://meet.google.com/usn-iqyu-tgg\n\nLearn more about Meet at: https: //support.google.com/a/users/answer/9282720\n\nPlease do not edit this sect ion.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~ :~:~:~:~:~::~:~::- LAST-MODIFIED:20240429T153200Z LOCATION: SEQUENCE:0 STATUS:CONFIRMED SUMMARY:OAuth WG Virtual Interim - OAuth 2.1 TRANSP:OPAQUE BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:This is an event reminder TRIGGER:-P0DT0H30M0S END:VALARM END:VEVENT END:VCALENDAR invite.ics Description: application/ics ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)
BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/Toronto X-LIC-LOCATION:America/Toronto BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:19700308T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:19701101T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTART;TZID=America/Toronto:20240507T12 DTEND;TZID=America/Toronto:20240507T13 DTSTAMP:20240425T170119Z ORGANIZER;CN=Rifaat Shekh-Yusef:mailto:rifaat.s.i...@gmail.com UID:0kvpotp8qj0jcqmnmkcra5p...@google.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE ;CN=Rifaat Shekh-Yusef;X-NUM-GUESTS=0:mailto:rifaat.s.i...@gmail.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=oauth@ietf.org;X-NUM-GUESTS=0:mailto:oauth@ietf.org X-MICROSOFT-CDO-OWNERAPPTID:-1300129712 CREATED:20240425T170118Z DESCRIPTION:The Web Authorization Protocol (oauth) WG will hold a virtual i nterim meetingon 2024-05-07 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC).Agenda:FedCM update and discussionhttps://fedidcg.github.io/F edCM/Information about remote participation:https://meetings.conf.meetecho.com/interim/?group=06583774-aede-401e-aa29- 4ed8f23365b8" target="_blank">https://meetings.conf.meetecho.com/int erim/?group=06583774-aede-401e-aa29-4ed8f23365b8 --A calendar subscription for all oauth meetings is available athttps://datatracker.ietf.org/meeting/upcoming.ics?show=oauth"; target= "_blank">https://datatracker.ietf.org/meeting/upcoming.ics?show=oaut h LAST-MODIFIED:20240425T170118Z LOCATION: SEQUENCE:0 STATUS:CONFIRMED SUMMARY:OAuth WG Virtual Interim - FedCM TRANSP:OPAQUE BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:This is an event reminder TRIGGER:-P0DT0H30M0S END:VALARM END:VEVENT END:VCALENDAR invite.ics Description: application/ics ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC for Cross-Device Flows BCP
We have not received any feedback on this document so far. This is a reminder to review and provide feedback on this document. If you reviewed the document, and you do not have any comments or concerns, it would be great if you can send an email to the list indicating that. Regards, Rifaat On Mon, Apr 15, 2024 at 9:32 AM Rifaat Shekh-Yusef wrote: > All, > > This is a *WG Last Call* for the *Cross-Device Flows BCP *document. > > https://www.ietf.org/archive/id/draft-ietf-oauth-cross-device-security-06.html > > Please, review this document and reply on the mailing list if you have any > comments or concerns, by *April 29th*. > > Regards, > Rifaat & Hannes > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata
rmine where to find the > resource metadata? > 2. Is this related to the inclusion of the URL for the protected > resource metadata as described in Section 5? > > >3. It looks like the validation rules in section 3.3 is intended as a >mitigation for the attack described in section 7.3 (Impersonation Attacks). >Perhaps add a sentence at the start of Section 3.3 to establish this >connection for implementors less familiar with different types of attacks. >For example: "The following validation rules mitigate against impersonation >attacks described in section 7.3." > > > > Section 4 > >1. Consider changing the first sentence to make it clear that the >"protected_resources" metadata value is used as part of the Authorization >Server Metadata. > > >1. For example: "To support use cases in which the set of legitimate > protected resources to use with the authorization server is fixed and > enumerable, this specification defines the protected_resources metadata > value, which enables the authorization server to explicitly list them as > part of the authorization server metadata" > > > > Section 5 > >1. For step 5 in the end-to-end flow, add a reference to the >validation steps described in Section 2.1 (validation of signed resource >metadata if it applies) and Section 3.3 >2. Representing this as fishbone diagram or flow-diagram showing the >interaction between the three parties may be helpful, perhaps even earlier >in the document, similar to other drafts. >3. Section 5.2: Perhaps rephrase the following sentence: "If the >client receives such a WWW-Authenticate response, it is expected >retrieve the protected resource metadata again, and SHOULD use the new >metadata values obtained." as "If the client receives such a >WWW-Authenticate response, it SHOULD retrieve the updated protected >resource metadata and use the new metadata values obtained." > > > > Section 6 > >1. I was unsure on how to interpret the reference to Section 8.3 in >RFC 8259. The way it is written creates the impression that all three >string validation rules in Section 6 is represented in section 8.3 of RFC >8259, but I could not find any reference to removal of JSON escaping or >prohibitions on normalization. Section 8.3 seems to only refer to code >point to code point comparison (the third validation rule). > > >1. Should the reference to RFC 8259 be limited to validation rule 3? > 2. It may be helpful to adopt the same language RFC 8259. RFC 8529 > talks about comparing code units, while the draft refers to code > points. I > assume they are the same, but perhaps just cleaner to use the same > description if they are. > > > > Section 7 > >1. Section 7.3: Similar to an earlier comment, if these attacks, >especially the attack in paragraph 2 is mitigated (fully or partially) by >the validation rules in section 3.3, it may be good to reference back to >that section. >2. Section 7.5: It is good to call out that the resource metadata >could be used by an attacker (its information they did not have before), >however the guidance to use "the same defenses against attacks that might >be mounted that use this information should be applied" feels a bit vague. >Is there a resource or a reference that describe those "same defenses"? >3. Section 7.6: The readability of this section may be improved by >first stating clearly what use cases are supported (as described in > paragraph 3) and then calling out that all other use cases are not >supported and why (paragraph 1 and 2). >4. Section 7.8: Not sure if this falls under phishing or if there >needs to be a separate section on malicious resource servers that uses >resource metadata to direct users to an authorization server under their >control in order to collect credentials (it is kind of hinted at, but not >explicitly stated). Defences would be similar to those typically deployed >against phishing sites as outlined in the last sentence of section 7.8 > > > > Cheers > > > > Pieter > > > > *From:* OAuth *On Behalf Of *Rifaat Shekh-Yusef > *Sent:* Wednesday, March 27, 2024 12:53 PM > *To:* oauth > *Subject:* [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata > > > > All, > > This is a *WG Last Call* for the *OAuth 2.0 Protected Resource Metadata* > document. > https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-03.html > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-resource-metadata-03.html&data=05%7C02%7Cpieter.kasselman%40microsoft.com%7C357b9c804c444b4a873d08dc4e5cfea1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638471408549324339%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=l3qRXme8ywpfuSzOCxZR3VX5WbBzoLNqZJA9KrQ8r7I%3D&reserved=0> > > Please, review this document and reply on the mailing list if you have any > comments or concerns, by *April 12*. > > Regards, > Rifaat & Hannes > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Signed JWK Sets
Just to be clear, this is *not* a call for adoption at this time. So, please focus on discussing the concept described in this individual draft. Regards, Rifaat On Wed, Apr 17, 2024 at 1:43 PM John Zila wrote: > On 11 Apr 2024, at 21:15, Neil Madden wrote: > > > I'm still digesting this draft, and generally supportive of it. However, > I don't think it stops the attack you mention here, which sounds similar to > threats that Ryan Sleevi discussed for FastFed in [1]. Essentially, in the > current OIDC model, an attacker that briefly compromises the jwks_uri of an > OP (e.g. through a mis-issued TLS cert) can serve a JWK Set containing > public keys under their own control with a long Cache-Control header. > Clients then might blindly cache that key set even beyond the time when the > certificate is revoked and the rightful owner restored. > > > > But I think this attack is basically the same even with PIKA. The > attacker in this case just uses their mis-issued cert to sign the PIKA and > serve that instead, perhaps putting a really long "exp" claim in it so that > clients cache it for a really long time. The only thing that would stop > that is if the draft insisted that clients regularly perform an OCSP or CRL > lookup on the cert in the x5c chain to make sure it hasn't been revoked. > But that would completely negate the benefits of avoiding clients all > hitting the OP jwks_uri: we've just shifted the burden from the OP to the > CA. > > I am also supportive of this draft. Chain of Trust is a real problem in > JWT issuance, and it's nice to see a simple solution that addresses it. > Regarding Neil's attack above, rather than requiring clients to separately > do OCSP or CRL, you could envision an OCSP stapling-like approach that > could include a signature over a timestamped PIKA as a "staple" in a JWT, > which moves up the proof of issuer validity to the time of issuance of the > JWT, rather than just the last time you retrieved the PIKA. If you see a > new PIKA staple, you know you need to fetch again. If you see a staple for > a PIKA you've already cached, then you know it hasn't been revoked. > > You could additionally layer this approach by stapling the PIKAs > themselves, where the PIKA staples are periodically updated to assert > continued validity of the signing certificate. With such a system, you can > provide guarantees regarding validity latency down the entire signature > chain. > > - John > ___ > 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] WGLC for Cross-Device Flows BCP
All, This is a *WG Last Call* for the *Cross-Device Flows BCP *document. https://www.ietf.org/archive/id/draft-ietf-oauth-cross-device-security-06.html Please, review this document and reply on the mailing list if you have any comments or concerns, by *April 29th*. Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Canceled Webex meeting: OAuth WG Virtual Office Hours
We cancelled the meeting for this week, because Hannes and I have conflicts. Regards, Rifaat On Mon, Apr 8, 2024 at 3:09 PM Rifaat Shekh-Yusef wrote: > > > Rifaat Shekh-Yusef canceled this Webex meeting. > > Wednesday, April 10, 2024 > 12:00 PM | (UTC-04:00) Eastern Time (US & Canada) | 30 mins > > Need help? Go to https://help.webex.com > > ___ > 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] Canceled Webex meeting: OAuth WG Virtual Office Hours
BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:CANCEL BEGIN:VTIMEZONE TZID:America/New_York LAST-MODIFIED:20221105T024526Z TZURL:https://www.tzurl.org/zoneinfo-outlook/America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZNAME:EDT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 DTSTART:19700308T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZNAME:EST TZOFFSETFROM:-0400 TZOFFSETTO:-0500 DTSTART:19701101T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20240408T190850Z ATTENDEE;CN="oauth@ietf.org";ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO:oauth@ietf.org ORGANIZER;CN="Rifaat Shekh-Yusef":MAILTO:oauth-cha...@ietf.org DTSTART;TZID=America/New_York:20240410T12 DTEND;TZID=America/New_York:20240410T123000 LOCATION:https://ietf.webex.com/ietf TRANSP:OPAQUE SEQUENCE:1712603330 UID:e5c0a906-b5f7-4a49-af60-e405c6e39c2a DESCRIPTION:\n\nThis Webex meeting has been canceled.\n\nTopic: OAuth WG Virtual Office Hours\nDate: Wednesday, April 10, 2024\nTime: 12:00 PM, (UTC-04:00) Eastern Time (US & Canada)\n SUMMARY:OAuth WG Virtual Office Hours PRIORITY:5 CLASS:PUBLIC RECURRENCE-ID;TZID=America/New_York:20240410T12 STATUS:CANCELLED END:VEVENT END:VCALENDAR Webex_meeting.ics Description: Binary data ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata
All, This is a *WG Last Call* for the *OAuth 2.0 Protected Resource Metadata* document. https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-03.html Please, review this document and reply on the mailing list if you have any comments or concerns, by *April 12*. Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] IETF119 OAuth WG Final Agenda
All, You can find the final agenda at the following link: https://datatracker.ietf.org/doc/agenda-119-oauth/ Regards, Rifaat ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] IETF119 - OAuth WG Draft Agenda
Presenters, Please, upload your slides to the following link as soon as possible: https://datatracker.ietf.org/meeting/119/session/oauth/ Regards, Rifaat On Mon, Mar 4, 2024 at 1:31 PM Rifaat Shekh-Yusef wrote: > All, > > The following is the draft agenda for Brisbane: > https://datatracker.ietf.org/doc/agenda-119-oauth/ > > Please, take a look and let us know if you have any questions/comments. > > Regards, > Rifaat & Hannes > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] IETF119 - OAuth WG Draft Agenda
All, The following is the draft agenda for Brisbane: https://datatracker.ietf.org/doc/agenda-119-oauth/ Please, take a look and let us know if you have any questions/comments. Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Fwd: IETF 119 Final Agenda
-- Forwarded message - From: IETF Agenda Date: Fri, Feb 23, 2024 at 5:53 PM Subject: IETF 119 Final Agenda To: Working Group Chairs IETF 119 Brisbane, Australia March 16-22, 2024 Hosted by: Google and Consortium members Key supporter: Brisbane Economic Development Agency IETF119 is supported by the Queensland Government through Tourism and Events Queensland and features on the It’s Live! in Queensland events calendar The IETF 119 Final Agenda is now available. At this point, only Area Directors may submit changes by suggesting a swap to supp...@ietf.org. https://datatracker.ietf.org/meeting/119/agenda While this is considered the final agenda, changes may be made to the agenda up to and during the meeting. Updates will be reflected on the datatracker agenda pages. ## Public Side Meetings At IETF 119, two rooms in the hotel will be made available for public side meetings. There are more details available on the wiki at: https://wiki.ietf.org/meeting/119/sidemeetings ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] IETF119 - Call for topics
This is a reminder to send us your topics for Brisbane, to help us plan properly! Regards, Rifaat & Hannes On Thu, Jan 25, 2024 at 1:44 PM Michael Jones wrote: > Please put time on the agenda to discuss > draft-ietf-oauth-resource-metadata. > > > > Thanks, > > -- Mike > > > > *From:* OAuth *On Behalf Of *Rifaat Shekh-Yusef > *Sent:* Wednesday, January 24, 2024 6:15 AM > *To:* oauth > *Subject:* [OAUTH-WG] IETF119 - Call for topics > > > > All, > > > > This is a call for topics for the coming IETF119 in Brisbane. > > > > Please, let us know *as soon as possible *if you have topics that you > would like to discuss. > > This will help us request enough sessions to address the requested topics. > > > > *Note that if we do not get the list before Feb 2nd, we might request less > sessions than we usually do.* > > *This might impact the time allocated to each topic or might force us to > drop some topics.* > > > > Regards, > > Rifaat & Hannes > > > > > > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] IETF119 - Call for topics
All, This is a call for topics for the coming IETF119 in Brisbane. Please, let us know *as soon as possible *if you have topics that you would like to discuss. This will help us request enough sessions to address the requested topics. *Note that if we do not get the list before Feb 2nd, we might request less sessions than we usually do.* *This might impact the time allocated to each topic or might force us to drop some topics.* Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] OAuth WG Virtual Office Hours cancelled today
All, Happy new year! I have cancelled the meeting for this week. Regards, Rifaat ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Canceled Webex meeting: OAuth WG Virtual Office Hours
BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:CANCEL BEGIN:VTIMEZONE TZID:America/New_York LAST-MODIFIED:20221105T024526Z TZURL:https://www.tzurl.org/zoneinfo-outlook/America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZNAME:EDT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 DTSTART:19700308T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZNAME:EST TZOFFSETFROM:-0400 TZOFFSETTO:-0500 DTSTART:19701101T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20240103T150803Z ATTENDEE;CN="oauth@ietf.org";ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO:oauth@ietf.org ORGANIZER;CN="Rifaat Shekh-Yusef":MAILTO:oauth-cha...@ietf.org DTSTART;TZID=America/New_York:20240103T12 DTEND;TZID=America/New_York:20240103T123000 LOCATION:https://ietf.webex.com/ietf TRANSP:OPAQUE SEQUENCE:1704294483 UID:e5c0a906-b5f7-4a49-af60-e405c6e39c2a DESCRIPTION:\n\nThis Webex meeting has been canceled.\n\nTopic: OAuth WG Virtual Office Hours\nDate: Wednesday, January 03, 2024\nTime: 12:00 PM, (UTC-05:00) Eastern Time (US & Canada)\n SUMMARY:OAuth WG Virtual Office Hours PRIORITY:5 CLASS:PUBLIC RECURRENCE-ID;TZID=America/New_York:20240103T12 STATUS:CANCELLED END:VEVENT END:VCALENDAR Webex_meeting.ics Description: Binary data ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Fwd: New Non-WG Mailing List: id-align (Identity Alignment)
If you are interested in Digital Identity, you might want to consider subscribing to this new mailing list. Regards, Rifaat -- Forwarded message - From: IETF Secretariat Date: Tue, Jan 2, 2024 at 11:17 AM Subject: New Non-WG Mailing List: id-align (Identity Alignment) To: IETF Announcement List Cc: , , A new IETF non-working group email list has been created. List address: id-al...@ietf.org Archive: https://mailarchive.ietf.org/arch/browse/id-align/ To subscribe: https://www.ietf.org/mailman/listinfo/id-align Purpose: When asked for a definition of identity, most people will offer a definition that they believe will be well understood by others, but few of the definitions will have significant overlap. This lack of alignment on the term identity extends to other terms of art, leading to confusion. In the multi-cloud era, any secure solution must have clear end-to-end identity mechanisms that span all identity layers: user, device, and workload. The rise of zero-trust requires well-defined identity solutions that enable the enforcement of the least-privilege principle. Executive orders and various regulations around cybersecurity are increasingly putting identity and privacy in the spotlight. The goal of this mailing list is to discuss how to align identity related work being done in the IETF. Specific alignment would include: • Collecting existing terminology and making it broadly available so that terms start to be used consistently. • Raising awareness of identity related work between identity related work streams This list belongs to IETF area: SEC For additional information, please contact the list administrators. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth WG Slack Channel
I changed the expiry of the link to one day. If people want to join after the expiry, ping me back. Regards, Rifaat On Thu, Dec 7, 2023 at 4:22 PM Warren Parad wrote: > Thanks! > > On Thu, Dec 7, 2023 at 10:09 PM Rifaat Shekh-Yusef < > rifaat.s.i...@gmail.com> wrote: > >> Warren, >> >> Try the following link: >> >> https://join.slack.com/t/ietf/shared_invite/zt-28l39r2bo-GnzrcjNGiXdZDJhVEQfwkQ >> >> The link will expire in 30 days. >> >> Regards, >> Rifaat >> >> >> On Thu, Dec 7, 2023 at 3:27 PM Warren Parad wrote: >> >>> Hmmm, it doesn't seem to work by email. At least not for me. >>> >>> Is this the official process: >>> https://www.spinics.net/lists/ietf/msg101574.html >>> >>> On Thu, Dec 7, 2023 at 8:58 PM Rifaat Shekh-Yusef < >>> rifaat.s.i...@gmail.com> wrote: >>> >>>> I think all you need is a datatracker account. >>>> >>>> Regards, >>>> Rifaat >>>> >>>> >>>> On Thu, Dec 7, 2023 at 1:16 PM Warren Parad wrote: >>>> >>>>> I didn't know there was a Slack Workspace for this. How does one get >>>>> an invite to the workspace? >>>>> >>>>> On Thu, Dec 7, 2023 at 7:04 PM Rifaat Shekh-Yusef < >>>>> rifaat.s.i...@gmail.com> wrote: >>>>> >>>>>> All, >>>>>> >>>>>> We now have an OAuth channel (#oauth) at the IETF Slack service. >>>>>> ietf.slack.com >>>>>> >>>>>> Feel free to join the channel if you use Slack. >>>>>> >>>>>> Regards, >>>>>> Rifaat & Hannes >>>>>> >>>>>> ___ >>>>>> 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] OAuth WG Slack Channel
Warren, Try the following link: https://join.slack.com/t/ietf/shared_invite/zt-28l39r2bo-GnzrcjNGiXdZDJhVEQfwkQ The link will expire in 30 days. Regards, Rifaat On Thu, Dec 7, 2023 at 3:27 PM Warren Parad wrote: > Hmmm, it doesn't seem to work by email. At least not for me. > > Is this the official process: > https://www.spinics.net/lists/ietf/msg101574.html > > On Thu, Dec 7, 2023 at 8:58 PM Rifaat Shekh-Yusef > wrote: > >> I think all you need is a datatracker account. >> >> Regards, >> Rifaat >> >> >> On Thu, Dec 7, 2023 at 1:16 PM Warren Parad wrote: >> >>> I didn't know there was a Slack Workspace for this. How does one get an >>> invite to the workspace? >>> >>> On Thu, Dec 7, 2023 at 7:04 PM Rifaat Shekh-Yusef < >>> rifaat.s.i...@gmail.com> wrote: >>> >>>> All, >>>> >>>> We now have an OAuth channel (#oauth) at the IETF Slack service. >>>> ietf.slack.com >>>> >>>> Feel free to join the channel if you use Slack. >>>> >>>> Regards, >>>> Rifaat & Hannes >>>> >>>> ___ >>>> 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] OAuth WG Slack Channel
I think all you need is a datatracker account. Regards, Rifaat On Thu, Dec 7, 2023 at 1:16 PM Warren Parad wrote: > I didn't know there was a Slack Workspace for this. How does one get an > invite to the workspace? > > On Thu, Dec 7, 2023 at 7:04 PM Rifaat Shekh-Yusef > wrote: > >> All, >> >> We now have an OAuth channel (#oauth) at the IETF Slack service. >> ietf.slack.com >> >> Feel free to join the channel if you use Slack. >> >> Regards, >> Rifaat & Hannes >> >> ___ >> 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 WG Slack Channel
All, We now have an OAuth channel (#oauth) at the IETF Slack service. ietf.slack.com Feel free to join the channel if you use Slack. Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [External Sender] Call for adoption - Transaction Tokens
All, Based on the feedback in Prague and the responses to this call for adoption, we declare the *Transaction Tokens *draft adopted as a WG document. Authors, Feel free to submit a -00 version of the WG document at your convenience, that has the same content of the latest individual document. Regards, Rifaat & Hannes On Wed, Nov 22, 2023 at 1:31 PM Steinar Noem wrote: > I support adoption of the draft for transaction tokens > > S > > On Tue, Nov 14, 2023 at 7:58 AM Rifaat Shekh-Yusef < > rifaat.s.i...@gmail.com> wrote: > >> All, >> >> This is an *official *call for adoption for the *Transaction Tokens * >> draft: >> >> https://datatracker.ietf.org/doc/draft-tulshibagwale-oauth-transaction-tokens/ >> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-tulshibagwale-oauth-transaction-tokens/__;!!FrPt2g6CO4Wadw!Nqr30iiI7ZlobJ7_w7VgmNrHUE-0eih96FtpdSgKwLDYFcOuo0_uHrDa8DEBi2mG0DqTFjZbP-FmrKIkAR5ww54RnE-jwMU$> >> >> Please, reply on the mailing list and let us know if you are in favor or >> against adopting this draft as WG document, by *Nov 28th*. >> >> Regards, >> Rifaat & Hannes >> ___ >> OAuth mailing list >> OAuth@ietf.org >> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!Nqr30iiI7ZlobJ7_w7VgmNrHUE-0eih96FtpdSgKwLDYFcOuo0_uHrDa8DEBi2mG0DqTFjZbP-FmrKIkAR5ww54RQJ2lbcI$ >> > -- > > > The information contained in this e-mail may be confidential and/or > proprietary to Capital One and/or its affiliates and may only be used > solely in performance of work or services for Capital One. The information > transmitted herewith is intended only for use by the individual or entity > to which it is addressed. If the reader of this message is not the intended > recipient, you are hereby notified that any review, retransmission, > dissemination, distribution, copying or other use of, or taking of any > action in reliance upon this information is strictly prohibited. If you > have received this communication in error, please contact the sender and > delete the material from your computer. > > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Call for adoption - Identity Chaining
All, Based on the feedback in Prague and the responses to this call for adoption, we declare the *Identity Chaining *draft *adopted* as a WG document. Authors, Feel free to submit a -00 version of the WG document at your convenience, that has the same content of the latest individual document. Regards, Rifaat & Hannes On Wed, Nov 22, 2023 at 1:25 PM Steinar Noem wrote: > I support adoption > > > -- > *Fra:* OAuth på vegne av > > > On Tue, Nov 14, 2023 at 4:59 AM Rifaat Shekh-Yusef < > rifaat.s.i...@gmail.com> wrote: > >> All, >> >> This is an *official* call for adoption for the *Identity Chaining * >> draft: >> >> https://datatracker.ietf.org/doc/draft-schwenkschuster-oauth-identity-chaining/ >> >> Please, reply on the mailing list and let us know if you are in favor or >> against adopting this draft as WG document, by *Nov 28th.* >> >> Regards, >> Rifaat & Hannes >> ___ >> 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] Call for adoption - Transaction Tokens
Dmitry, Atul, Any member of the WG can post an opinion on the list on whether we should adopt this document or not. At the end of the call for adoption, the chairs will assess all the replies and make a decision on the result of that call. Regards, Rifaat On Wed, Nov 15, 2023 at 5:21 PM Dmitry Telegin wrote: > Hi Atul, thanks for the link - perhaps it could be included into the > "About This Document" section? > Aaron's recent draft is a great example of the same: > https://datatracker.ietf.org/doc/draft-parecki-oauth-first-party-apps/ > > Dmitry > > On Wed, Nov 15, 2023 at 10:15 PM Atul Tulshibagwale wrote: > >> Hi Dmitry, >> Even if it doesn't count (and I too am not familiar with the voting >> rules), you can still record your vote by sending an email to this list. >> >> The issue tracker is here for now: >> https://github.com/SGNL-ai/transaction-tokens/issues >> Atul >> >> >> On Wed, Nov 15, 2023 at 2:10 PM Dmitry Telegin > 40backbase@dmarc.ietf.org> wrote: >> >>> Not sure if I have formal right to vote, will just state that we are >>> currently using something very similar internally, and will be looking >>> forward to adopting a standards-based approach. >>> >>> BTW is there an issue tracker for this one? couldn't find links to GH >>> etc. >>> >>> Thanks, >>> Dmitry >>> Backbase / Keycloak >>> >>> On Wed, Nov 15, 2023 at 4:40 PM Pieter Kasselman >> 40microsoft@dmarc.ietf.org> wrote: >>> >>>> I support adoption. >>>> >>>> >>>> >>>> *From:* OAuth *On Behalf Of *Rifaat >>>> Shekh-Yusef >>>> *Sent:* Tuesday, November 14, 2023 12:58 PM >>>> *To:* oauth >>>> *Subject:* [OAUTH-WG] Call for adoption - Transaction Tokens >>>> >>>> >>>> >>>> All, >>>> >>>> This is an *official *call for adoption for the *Transaction Tokens * >>>> draft: >>>> >>>> https://datatracker.ietf.org/doc/draft-tulshibagwale-oauth-transaction-tokens/ >>>> >>>> Please, reply on the mailing list and let us know if you are in favor >>>> or against adopting this draft as WG document, by *Nov 28th*. >>>> >>>> Regards, >>>> Rifaat & Hannes >>>> ___ >>>> 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 > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Call for adoption - Identity Chaining
All, This is an *official* call for adoption for the *Identity Chaining *draft: https://datatracker.ietf.org/doc/draft-schwenkschuster-oauth-identity-chaining/ Please, reply on the mailing list and let us know if you are in favor or against adopting this draft as WG document, by *Nov 28th.* Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Call for adoption - Transaction Tokens
All, This is an *official *call for adoption for the *Transaction Tokens *draft: https://datatracker.ietf.org/doc/draft-tulshibagwale-oauth-transaction-tokens/ Please, reply on the mailing list and let us know if you are in favor or against adopting this draft as WG document, by *Nov 28th*. Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Webex meeting invitation: OAuth WG Virtual Office Hours
All, As discussed during the last IETF meeting in Prague, this is the new invitation for the OAuth WG Virtual Office Hours meeting. Please, remove all previous invitations you might still have on your calendar. Regards, Rifaat On Mon, Nov 13, 2023 at 1:22 PM Rifaat Shekh-Yusef wrote: > > Rifaat Shekh-Yusef is inviting you to a scheduled Webex meeting. > > Occurs every 2 week(s) on Wednesday effective Wednesday, November 22, 2023 > from 12:00 PM to 12:30 PM, (UTC-05:00) Eastern Time (US & Canada) > 12:00 PM | (UTC-05:00) Eastern Time (US & Canada) | 30 mins > > Join meeting > <https://ietf.webex.com/ietf/j.php?MTID=m6fc3cd55e3ac55805f45b7859db40468> > > *More ways to join:* > > *Join from the meeting link* > https://ietf.webex.com/ietf/j.php?MTID=m6fc3cd55e3ac55805f45b7859db40468 > > *Join by meeting number* > Meeting number (access code): 2420 449 7527 > Meeting password: DrmT3tEFv87 > > *Tap to join from a mobile device (attendees only)* > +1-650-479-3208,,24204497527## > <%2B1-650-479-3208,,*01*24204497527%23%23*01*> Call-in toll number > (US/Canada) > > *Join by phone* > 1-650-479-3208 Call-in toll number (US/Canada) > Global call-in numbers > <https://ietf.webex.com/ietf/globalcallin.php?MTID=mfca18fef35772abd879c4e25d50d81b0> > > *Join from a video system or application* > Dial 24204497...@ietf.webex.com > You can also dial 173.243.2.68 and enter your meeting number. > > > Need help? Go to https://help.webex.com > ___ > 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] Webex meeting invitation: OAuth WG Virtual Office Hours
BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/New_York
LAST-MODIFIED:20221105T024526Z
TZURL:https://www.tzurl.org/zoneinfo-outlook/America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20231113T182216Z
ATTENDEE;CN="oauth@ietf.org";ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO:oauth@ietf.org
ORGANIZER;CN="Rifaat Shekh-Yusef":MAILTO:oauth-cha...@ietf.org
DTSTART;TZID=America/New_York:20231122T12
DTEND;TZID=America/New_York:20231122T123000
LOCATION:https://ietf.webex.com/ietf/j.php?MTID=m6fc3cd55e3ac55805f45b7859db40468
TRANSP:OPAQUE
SEQUENCE:1699899736
UID:e5c0a906-b5f7-4a49-af60-e405c6e39c2a
DESCRIPTION:\n\n\n\n\n\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=m6fc3cd55e3ac55805f45b7859db40468\nMeeting number (access code): 2420 449 7527\n\nMeeting password: DrmT3tEFv87\n\n\n\nTAP TO JOIN FROM A MOBILE DEVICE (ATTENDEES ONLY)\n+1-650-479-3208,,24204497527## tel:%2B1-650-479-3208,,*01*24204497527%23%23*01* Call-in toll number (US/Canada)\n\n\nJOIN BY PHONE\n1-650-479-3208 Call-in toll number (US/Canada)\n\nGlobal call-in numbers\nhttps://ietf.webex.com/ietf/globalcallin.php?MTID=mfca18fef35772abd879c4e25d50d81b0\n\n\nJOIN FROM A VIDEO SYSTEM OR APPLICATION\nDial sip:24204497...@ietf.webex.com\nYou can also dial 173.243.2.68 and enter your meeting number.\n\n\n\n\n\nCan't join the meeting?\nhttps://collaborationhelp.cisco.com/article/WBX29055\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. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.\n
X-ALT-DESC;FMTTYPE=text/html:\ntable {\n border-collapse: separate; width =100%;border: 0;border-spacing: 0;}\n\ntr {\n line-height: 18px;}\n\na, td {\n font-size: 14px; font-family: Arial; color: #333; word-wrap: break-word; word-break: normal; padding: 0;}\n\n.title {\n font-size: 28px;}\n\n.image {\n width: auto; max-width: auto;}\n\n.footer {\n width: 604px;}\n\n.main {\n\n}@media screen and (max-device-width: 800px) {\n .title {\n font-size: 22px !important; }\n .image {\n width: auto !important; max-width: 100% !important; }\n .footer {\n width: 100% !important; max-width: 604px !important\n }\n .main {\n width: 100% !important; max-width: 604px !important\n }\n}\n\n\n\n \n \n \n \n\n\n\n\n\n \n\n \n When it's time, join the Webex meeting here.\n \n\n \n\n\n \n \n\n \n \n https://ietf.webex.com/ietf/j.php?MTID=m6fc3cd55e3ac55805f45b7859db40468"; style="color:#FF; font-size:20px; text-decoration:none;">Join meeting\n \n \n\n \n \n \n \n \n\n More ways to join:\n\n \n \n \n\n Join from the meeting link\n\n \n \n\n https://ietf.webex.com/ietf/j.php?MTID=m6fc3cd55e3ac55805f45b7859db40468\n\n \n \n \n\n Join by meeting number\n\n \n \n\n Meeting number (access code): 2420 449 7527\n\n \n \n Meeting password:DrmT3tEFv87\n\n \n\n Tap to join from a mobile device (attendees only) +1-650-479-3208,,24204497527## Call-in toll number (US/Canada) Join by phone 1-650-479-3208 Call-in toll number (US/Canada) https://ietf.webex.com/ietf/globalcallin.php?MTID=mfca18fef35772abd879c4e25d50d81b0"; style="text-decoration:none;font-size:14px;color:#005E7D">Global call-in numbers \n\n \n\nJoin from a video system or applicationDial 24204497...@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. \n\n \n \n\n \n \n\n Need help? Go to https://help.webex.com"; style="color:#005E7D; text-decoration:none;">https://help.webex.com\n \n\n \n \n \n \n\n
SUMMARY:OAuth WG Virtual Office Hours
PRIORITY:5
CLASS:PUBLIC
RRULE:FREQ=WEEKLY;WKST=SU;INTERVAL=2;BYDAY=WE
BEGIN:VALARM
TRIGGER:-PT5M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR
Webex_meeting.ics
Description: Binary data
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Publication has been requested for draft-ietf-oauth-security-topics-24
Rifaat Shekh-Yusef has requested publication of draft-ietf-oauth-security-topics-24 as Best Current Practice on behalf of the OAUTH working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] IETF118 - OAuth WG Final Agenda
All, Here is our final agenda for Prague: https://datatracker.ietf.org/doc/agenda-118-oauth/ Regards, Rifaat & Hannes Tuesday (60 min) - Chairs update – Rifaat Shekh-Yusef/Hannes Tschofenig (15 min) - Charter discussion (30 min) - SD-JWT – Kristina Yasuda/Daniel Fett – (15 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/ Wednesday (120 min) - Protected Resource Metadata – Mike Jones, Aaron Parecki (20 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/ - SD-JWT-based Verifiable Credentials (SD-JWT VC) – Oliver Terbu, Daniel Fett (20 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/ - Attestation-Based Client Authentication – Paul Bastian (20 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/ - Browser-Based Apps - Aaron Parecki (20 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ - Cross-Device Flows – Pieter Kasselman (15 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/ - OAuth Status List - Paul Bastian (20 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/ Friday (120 min) - Transaction Tokens – George Fletcher (20 min) https://datatracker.ietf.org/doc/draft-tulshibagwale-oauth-transaction-tokens/ - Identity Chaining – Pieter Kasselman (20 min) https://datatracker.ietf.org/doc/draft-schwenkschuster-oauth-identity-chaining/ - The Use of Attestation in DCR – Ned Smith (20 min) https://datatracker.ietf.org/doc/draft-tschofenig-oauth-attested-dclient-reg/ - First-Party Native Applications - Aaron Parecki (20 min) https://datatracker.ietf.org/doc/draft-parecki-oauth-first-party-apps/ - OAuth Client and Device Metadata for Nested Flows - Aaron Parecki (20 min) https://datatracker.ietf.org/doc/draft-parecki-oauth-metadata-for-nested-flows/ - Any other business (20 min) ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Canceled Webex meeting: OAuth WG Virtual Office Hours
BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:CANCEL BEGIN:VTIMEZONE TZID:America/New_York LAST-MODIFIED:20221105T024526Z TZURL:https://www.tzurl.org/zoneinfo-outlook/America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZNAME:EDT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 DTSTART:19700308T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZNAME:EST TZOFFSETFROM:-0400 TZOFFSETTO:-0500 DTSTART:19701101T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20231026T121827Z ATTENDEE;CN="oauth@ietf.org";ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO:oauth@ietf.org ORGANIZER;CN="Rifaat Shekh-Yusef":MAILTO:oauth-cha...@ietf.org DTSTART;TZID=America/New_York:20211006T12 DTEND;TZID=America/New_York:20211006T123000 LOCATION:https://ietf.webex.com/ietf TRANSP:OPAQUE SEQUENCE:1698322707 UID:2045d357-fe78-490a-b904-560dc7ae3602 DESCRIPTION:\n\nThis Webex meeting has been canceled.\n\nTopic: OAuth WG Virtual Office Hours\nDate: Occurs every 2 week(s) on Wednesday effective Wednesday, October 06, 2021 from 12:00 PM to 12:30 PM, (UTC-04:00) Eastern Time (US & Canada)\nTime: 6:00 PM, (UTC+02:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna\n SUMMARY:OAuth WG Virtual Office Hours PRIORITY:5 CLASS:PUBLIC RRULE:FREQ=WEEKLY;WKST=SU;INTERVAL=2;BYDAY=WE STATUS:CANCELLED END:VEVENT END:VCALENDAR Webex_meeting.ics Description: Binary data ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] IETF118 - Draft agenda
Fixed few typos: https://datatracker.ietf.org/meeting/118/materials/agenda-118-oauth-02 Regards, Rifaat On Wed, Oct 25, 2023 at 4:23 PM Rifaat Shekh-Yusef wrote: > All, > > Here is our *draft* agenda for the meeting in Prague: > https://datatracker.ietf.org/meeting/118/materials/agenda-118-oauth-00 > > Please, let us know if we missed anything. > > Regards, > Rifaat & Hannes > > > > > > > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] IETF118 - Draft agenda
All, Here is our *draft* agenda for the meeting in Prague: https://datatracker.ietf.org/meeting/118/materials/agenda-118-oauth-00 Please, let us know if we missed anything. Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List
> > I also noticed you didn't mark it as replacing the individual draft in > datatracker. You can email supp...@ietf.org and request that they mark it > as replacing > https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/ so > that the history tracks better. > I fixed that. Regards, Rifaat On Mon, Oct 23, 2023 at 10:35 AM Aaron Parecki wrote: > Tobias, Paul, Christian, > > I just noticed the new working group adopted version of this draft: > https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/ > > I posted this comment on Github, but I'll repeat it here for others. I > find the new name "OAuth Status List" confusing. While I understand wanting > to remove "JWT" and "CWT" from the name, I was not aware of that discussion > during the call for adoption. I would suggest renaming this to "OAuth Token > Status List" instead. > > I also noticed you didn't mark it as replacing the individual draft in > datatracker. You can email supp...@ietf.org and request that they mark it > as replacing > https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/ > so that the history tracks better. > > I also noticed that there are significant changes to the draft between the > individual and working group versions. Typically it is better to post a > verbatim copy of the individual draft as the adopted version, and then make > changes in a -01 version. > > Thanks! > > Aaron > > > > On Sat, Oct 14, 2023 at 5:56 AM Rifaat Shekh-Yusef < > rifaat.s.i...@gmail.com> wrote: > >> All, >> >> Based on the feedback to this call for adoption, we declare this document >> adopted as a WG document. >> >> >> Authors, >> >> Please, submit this as a working group document at your earliest >> convenience. >> >> Regards, >> Rifaat & Hannes >> >> >> >> >> >> >> On Tue, Oct 3, 2023 at 8:51 PM John Bradley wrote: >> >>> +1 for adoption >>> >>> On Sat, Sep 30, 2023, 9:53 AM Rifaat Shekh-Yusef < >>> rifaat.s.i...@gmail.com> wrote: >>> >>>> All, >>>> >>>> This is an official call for adoption for the *JWT and CWT Status List* >>>> draft: >>>> https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/ >>>> >>>> Please, reply *on the mailing list *and let us know if you are in *favor >>>> *or* against *adopting this draft as WG document, by *Oct 13th*. >>>> >>>> Regards, >>>> Rifaat & Hannes >>>> ___ >>>> 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
[OAUTH-WG] NomCom: Selecting IETF Leadership
All, The *NomCom *is tasked with selecting the *IETF leadership*, like the IESG and the IAB. For the NomCom to be able to make an informed decision, they need feedback from the *wider IETF community*. Please, consider allocating some time to provide feedback on people that you interacted with to help the NomCom with their important task. The deadline for this feedback is *Nov 3rd*: https://datatracker.ietf.org/nomcom/2023/feedback/ Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List
All, Based on the feedback to this call for adoption, we declare this document adopted as a WG document. Authors, Please, submit this as a working group document at your earliest convenience. Regards, Rifaat & Hannes On Tue, Oct 3, 2023 at 8:51 PM John Bradley wrote: > +1 for adoption > > On Sat, Sep 30, 2023, 9:53 AM Rifaat Shekh-Yusef > wrote: > >> All, >> >> This is an official call for adoption for the *JWT and CWT Status List* >> draft: >> https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/ >> >> Please, reply *on the mailing list *and let us know if you are in *favor >> *or* against *adopting this draft as WG document, by *Oct 13th*. >> >> Regards, >> Rifaat & Hannes >> ___ >> 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] Vittorio Luigi Bertocci
All, In the world of the Digital Identity community, a brilliant star has dimmed with the passing of *Vittorio Luigi Bertocci*, a true luminary in the field. His departure has left a void in the hearts of those who admired and respected him. Vittorio left a great legacy with the OAuth Working Group at the IETF, and his numerous contributions resonate within the entire Digital Identity community. Through his tireless efforts, he elevated the standards of the field, leaving lasting marks on the IETF, OpenID Foundations, and numerous other Identity organizations. Beyond his remarkable technical abilities, Vittorio was an exceptional educator and author, illuminating the complex world of Digital Identity for others. His wisdom and insights reached far and wide, touching the lives of countless individuals. His voice became a beacon of knowledge and understanding, exemplified in his popular podcast, "Identity Unlocked," where he generously shared his expertise and passion with the world. As a Principal Architect at Auth0/Okta and previously at Microsoft, Vittorio's contributions were monumental. His work on identity solutions for developers was ground-breaking, shaping the way we perceive and interact with digital identities. His innovative spirit and dedication to the craft inspired colleagues and enthusiasts alike, leaving an enduring impact on the industry. The Digital Identity community and the OAuth Working Group at the IETF mourn the loss of Vittorio deeply. His absence is felt profoundly, reminding us of the void created by his departure. Yet, as we bid farewell, we celebrate a life well-lived, a legacy that will continue to inspire generations to come. In the quiet moments, as we reflect on his extraordinary journey, we remember Vittorio with gratitude and reverence. May he find eternal peace! Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] IETF118 - Call for topics
All, As per the preliminary agenda, we have 3 sessions in Prague: 1. *Tuesday *at 15:30-16:30 2. *Wednesday *at 14:30-16:30 3. *Friday *at 13:00-15:00 Please, reply to this email or directly to the chairs if you have topics that you would like to discuss. Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth and JWT/VC documents
Thanks Giuseppe! Please, reply to the *official* call for adoption email. Regards, Rifaat On Fri, Sep 29, 2023 at 6:26 PM Giuseppe De Marco wrote: > Ciao Rifaat > > I can say in the vest of an implementer, that VC documents are like > unrequited love, you know you need it but it's not something you can build > on. > > Here I represent many organizations that are working to build on these, > with deadlines. > > I express my strong support for these brand new specs, since I Need them > and I share the vision behind them. All about how these can became reality > would be search and found in a OAuth WG that would show how this would be > then possible. > > I support the adoption and I'm implementing the so called vcstuff drafts > > Il ven 29 set 2023, 20:16 Rifaat Shekh-Yusef ha > scritto: > >> There are two reasons for not calling for the adoption of this document: >> 1. The SPICE discussion, which gave the impression that the plan is to >> migrate this to a new dedicated WG. >> 2. Some people questioned whether this is in scope or not. >> >> If the first one is not an issue, and there is no plan to migrate this to >> a different WG, then we can definitely start a call for adoption and see >> what happens. >> >> Regards, >> Rifaat >> >> >> On Fri, Sep 29, 2023 at 1:42 PM Kristina Yasuda > 40microsoft@dmarc.ietf.org> wrote: >> >>> +1 to Brian’s and Orie’s observations. >>> >>> >>> >>> During last IETF, a question was asked whether >>> draft-looker-oauth-jwt-cwt-status-list draft is (or [*]) is in scope of >>> OAuth WG charter or not. A lot of comments observed that it is because as >>> Brian has succinctly put it “a general JWT status/revocation mechanism (as >>> defined in this draft) would fall easily within the remit of the WG as is”. >>> >>> >>> >>> I also agree that it seems that focus has been unintentionally shifted >>> away from working on this status list draft, which there is an interest and >>> a need from the implementers to work on it. It would be great if we can >>> discuss and agree whether this draft is in scope for oauth wg or not and if >>> so whether we can start the call for adoption. >>> >>> >>> >>> Best, >>> >>> Kristina >>> >>> >>> >>> *From:* Orie Steele >>> *Sent:* Friday, September 29, 2023 10:35 AM >>> *To:* Brian Campbell >>> *Cc:* Torsten Lodderstedt ; torsten= >>> 40lodderstedt@dmarc.ietf.org; Kristina Yasuda < >>> kristina.yas...@microsoft.com>; oauth ; Paul Bastian < >>> paul.bast...@bdr.de>; Christian Bormann < >>> christiancarl.borm...@de.bosch.com> >>> *Subject:* Re: [OAUTH-WG] OAuth and JWT/VC documents >>> >>> >>> >>> Inline: >>> >>> >>> >>> On Fri, Sep 29, 2023 at 12:05 PM Brian Campbell < >>> bcampb...@pingidentity.com> wrote: >>> >>> >>> >>> If I might offer an observation... >>> >>> >>> >>> The draft-looker-oauth-jwt-cwt-status-list draft is (or can easily >>> be[*]) really just a generic status/revocation checking mechanism for JWTs >>> in general. Given the history/lineage of JWT development within the OAuth >>> WG, it seems like a general JWT status/revocation mechanism would fall >>> easily within the remit of the WG as is. >>> >>> >>> I agree with this. >>> >>> >>> >>> >>> It seems to me as though the prospect of the formation of a new WG from >>> the potential SPICE BoF that may or may not be a suitable future forum for >>> the status list work has unintentionally delayed or diverted >>> attention around consideration of the status list work being adopted and >>> progressed in OAuth in the more near term. >>> >>> >>> >>> >>> Speaking as a contributor to SPICE BoF, this was certainly never my >>> intention. >>> >>> I don't think work should be delayed if it is well solved within an >>> existing working group, and I agree that status lists are relevant to JWT >>> and CWT generally, not just credentials. >>> >>> >>> >>> >>> [*] it has some open TODOs for CWT based representations but no actual >>> content as such, which could be removed to focus the scope of the draft. >>> >>> >>> >
[OAUTH-WG] Call for adoption - JWT and CWT Status List
All, This is an official call for adoption for the *JWT and CWT Status List* draft: https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/ Please, reply *on the mailing list *and let us know if you are in *favor *or* against *adopting this draft as WG document, by *Oct 13th*. Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth and JWT/VC documents
There are two reasons for not calling for the adoption of this document: 1. The SPICE discussion, which gave the impression that the plan is to migrate this to a new dedicated WG. 2. Some people questioned whether this is in scope or not. If the first one is not an issue, and there is no plan to migrate this to a different WG, then we can definitely start a call for adoption and see what happens. Regards, Rifaat On Fri, Sep 29, 2023 at 1:42 PM Kristina Yasuda wrote: > +1 to Brian’s and Orie’s observations. > > > > During last IETF, a question was asked whether > draft-looker-oauth-jwt-cwt-status-list draft is (or [*]) is in scope of > OAuth WG charter or not. A lot of comments observed that it is because as > Brian has succinctly put it “a general JWT status/revocation mechanism (as > defined in this draft) would fall easily within the remit of the WG as is”. > > > > I also agree that it seems that focus has been unintentionally shifted > away from working on this status list draft, which there is an interest and > a need from the implementers to work on it. It would be great if we can > discuss and agree whether this draft is in scope for oauth wg or not and if > so whether we can start the call for adoption. > > > > Best, > > Kristina > > > > *From:* Orie Steele > *Sent:* Friday, September 29, 2023 10:35 AM > *To:* Brian Campbell > *Cc:* Torsten Lodderstedt ; torsten= > 40lodderstedt@dmarc.ietf.org; Kristina Yasuda < > kristina.yas...@microsoft.com>; oauth ; Paul Bastian < > paul.bast...@bdr.de>; Christian Bormann < > christiancarl.borm...@de.bosch.com> > *Subject:* Re: [OAUTH-WG] OAuth and JWT/VC documents > > > > Inline: > > > > On Fri, Sep 29, 2023 at 12:05 PM Brian Campbell < > bcampb...@pingidentity.com> wrote: > > > > If I might offer an observation... > > > > The draft-looker-oauth-jwt-cwt-status-list draft is (or can easily be[*]) > really just a generic status/revocation checking mechanism for JWTs in > general. Given the history/lineage of JWT development within the OAuth WG, > it seems like a general JWT status/revocation mechanism would fall easily > within the remit of the WG as is. > > > I agree with this. > > > > > It seems to me as though the prospect of the formation of a new WG from > the potential SPICE BoF that may or may not be a suitable future forum for > the status list work has unintentionally delayed or diverted > attention around consideration of the status list work being adopted and > progressed in OAuth in the more near term. > > > > > Speaking as a contributor to SPICE BoF, this was certainly never my > intention. > > I don't think work should be delayed if it is well solved within an > existing working group, and I agree that status lists are relevant to JWT > and CWT generally, not just credentials. > > > > > [*] it has some open TODOs for CWT based representations but no actual > content as such, which could be removed to focus the scope of the draft. > > > > > +1 > > > > > > > On Tue, Sep 19, 2023 at 1:56 PM Orie Steele > wrote: > > Excellent. > > Inline: > > > > On Tue, Sep 19, 2023 at 2:12 PM wrote: > > Hi Orie, > > > > best regards, > > Torsten. > > Am 18. Sept. 2023, 16:01 +0200 schrieb Orie Steele < > orie@transmute.industries>: > > Torsten, > > Thanks for sharing this excellent framing. > > I agree with everything you said. > > Please correct me if I'm wrong about anything in this summary: > > 1. Keep working on JWT based credential formats at OAuth (implicit, don't > expand OAuth charter to work on CWT credential formats ?) > > yes > > 2. If a new working group (SPICE) is formed focused on credentials, > authors are open moving credential specific work items there, and don't > plan new credential related items at OAuth. > > We are open to move the credential work to a new working group. We are > open to discuss whether that will be SPICE, so far it seems to be COSE > centric. It’s clearly in everyone’s interest to have the JSON and COSE > based credential formats aligned. > > > I agree, I think a big part of this comes from trying to respect the work > that has already happened, in JSON-LD at W3C and JSON / JOSE at OAuth and > OIDF. > > > 3. Coordinate with CBOR based credential formats (wherever they may be) to > ensure that architecture and conventions are as aligned as possible > > yes > > > Happy to help however I can, regardless of where work items land. > > Let’s talk about how we can bring the COSE and JSON credential work > together. > > > > Awesome, I think the most impactful way to achieve this would be adding a > sentence like this to the SPICE BoF request, something to the effect of: > > The following documents would be transitioned from OAuth to SPICE if the > WG forming BoF is successful. > > - draft-ietf-oauth-sd-jwt-vc > - draft-looker-oauth-jwt-cwt-status-list > > It's debatable if the status list work item should move, since I see that > as a generic token format that has applications beyond credentials. > > However, if authors fe
Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata
All, Based on the responses on this thread, we declare the *Protected Resource Metadata* draft adopted as a WG document. Authors, Feel free to submit a WG document at your convenience. Regards, Rifaat & Hannes On Mon, Aug 28, 2023 at 5:28 AM Takahiko Kawasaki wrote: > I support adoption. > > In the past, when considering the encryption of JWT access tokens, I > learned that the draft regarding the metadata of the resource server had > expired, which was disappointing. For an authorization server to encrypt an > access token with an asymmetric algorithm, it must obtain a public key of > the target resource server, but there was no standardized way. I'm glad to > see the specification has been revived. If it had been revived a bit > earlier, the addition that was made as "client" metadata in the "JWT > Response for OAuth Token Introspection" specification would likely have > been treated as metadata for the "resource server." > > Best Regards, > Takahiko Kawasaki > > > On Thu, Aug 24, 2023 at 4:02 AM Rifaat Shekh-Yusef < > rifaat.s.i...@gmail.com> wrote: > >> All, >> >> This is an official call for adoption for the *Protected Resource >> Metadata* draft: >> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/ >> >> Please, reply on the mailing list and let us know if you are in favor of >> adopting this draft as WG document, by *Sep 6th.* >> >> Regards, >> Rifaat & Hannes >> >> ___ >> 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] Fwd: NomCom 2023 Reminder that Nominations are Open
-- Forwarded message - From: NomCom Chair 2023 Date: Wed, Aug 23, 2023 at 1:37 PM Subject: NomCom 2023 Reminder that Nominations are Open To: IETF Announcement List All, The 2023-2024 nominating committee would like to thank everyone who has nominated someone for positions and especially those who have accepted a nomination. Nominations are still open. If you know someone (including yourself) who you think might be suited to one of the open positions on the IAB, IESG, IETF LLC Board, or IETF Trust, please nominate that person here: https://datatracker.ietf.org/nomcom/2023/nominate/ See https://mailarchive.ietf.org/arch/msg/ietf-announce/dDOlAKpmLNAjzo9rZ4p_HA6pIiw/ for more details. Martin Thomson nomcom-chair-2...@ietf.org (for nominations or questions) ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Call for adoption - Protected Resource Metadata
All, This is an official call for adoption for the *Protected Resource Metadata* draft: https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/ Please, reply on the mailing list and let us know if you are in favor of adopting this draft as WG document, by *Sep 6th.* Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Call for adoption - Attestation-Based Client Authentication
All, Based on the responses to this call for adoption, we declare the *Attestation-Based Client Authentication* draft adopted as a WG document. Authors, Feel free to submit a WG document at your convenience. Regards, Rifaat & Hannes On Tue, Aug 8, 2023 at 11:51 AM Paul Bastian wrote: > Being the co-author of this draft, I support adoption of Attestation-Based > Client Authentication :) > > ___ > 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] Call for adoption - SD-JWT-based Verifiable Credentials
All, Based on the responses to this call for adoption, we declare the *SD-JWT-based Verifiable Credentials* draft adopted as a WG document. Authors, Feel free to submit a WG document at your convenience. Regards, Rifaat & Hannes On Tue, Aug 8, 2023 at 11:51 AM Paul Bastian wrote: > I support the adoption of SD-JWT-based Verifiable Credentials. > > ___ > 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] WGLC for Browser-based Apps
All, This is a *WG Last Call *for the* Browser-based Apps* draft. https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-14.html Please, review this document and reply on the mailing list if you have any comments or concerns, by *August 11th*. Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Call for adoption - Attestation-Based Client Authentication
All, This is an official call for adoption for the *Attestation-Based Client Authentication *draft discussed in SF. https://datatracker.ietf.org/doc/draft-looker-oauth-attestation-based-client-auth/ Please, reply on the mailing list and let us know if you are in favor of adopting this draft as WG document, by *August 11th*. Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Call for adoption - SD-JWT-based Verifiable Credentials
All, This is an official call for adoption for the *SD-JWT-based Verifiable Credentials *draft discussed in SF. https://datatracker.ietf.org/doc/draft-terbu-oauth-sd-jwt-vc/ Please, reply on the mailing list and let us know if you are in favor of adopting this draft as WG document, by *August 11th*. Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] OAuth WG Sessions @ IETF117
All, There seems to be some confusion about the number of OAuth WG sessions. We have *THREE* sessions this week. The session that was initially scheduled on Thursday is now *cancelled*, and instead we have a new session on *Tuesday*. In summary, we have sessions on *Tuesday*, *Wednesday*, and *Friday*, all starting at 9:30am. Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] IETF117 OAuth WG Agenda Change
All, The agenda for the OAuth WG has changed. Our 3 sessions are now on *Tuesday*, *Wednesday* and *Friday* all at *9:30am*. Here is a link to the updated agenda: https://datatracker.ietf.org/meeting/117/materials/agenda-117-oauth-08 Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] IETF117 - OAuth WG Agenda
All, Below is the IETF117 OAuth WG *final *agenda. https://datatracker.ietf.org/doc/agenda-117-oauth/ Regards, Rifaat & Hannes Wednesday - Chairs update – Rifaat Shekh-Yusef/Hannes Tschofenig (15 min) - SD-JWT – Kristina Yasuda/Brian Campbell– (20 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/ - Browser-based Apps – Aaron Parecki (15 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ - OAuth 2.1 – Aaron Parecki (15 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/ - Resource Server Metadata – Mike Jones (20 min) https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/ - Cross-device flow - Pieter Kasselman (15 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/ - Attestation in Dynamic Client Registration - Hannes Tschofenig (20) https://datatracker.ietf.org/doc/draft-tschofenig-oauth-attested-dclient-reg/ Thursday - JWT Embedded Tokens – Dick Hardt/Rifaat Shekh-Yusef (30 min) https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/ - Transaction Tokens – Atul Tulshibagwale (30 min) https://datatracker.ietf.org/doc/draft-tulshibagwale-oauth-transaction-tokens/ - Cross Domain Identity Chaining – Pieter Kasselman (30 min) https://datatracker.ietf.org/doc/draft-identity-chaining/ - First party native apps - Aaron Parecki (30 min) https://datatracker.ietf.org/doc/draft-parecki-oauth-first-party-native-apps/ Friday - State of Play of the European Digital Identity Wallet – Paolo De Rosa (30 min) - SD-JWT-based Verifiable Credentials – Oliver Terbu (30 min) https://datatracker.ietf.org/doc/draft-terbu-oauth-sd-jwt-vc/ - JWT and CWT Status List – Tobias Looker/Paul Bastian (30 min) https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/ - Attestation-Based Client Authentication – Tobias Looker/Paul Bastian (30 min) https://datatracker.ietf.org/doc/draft-looker-oauth-attestation-based-client-auth/ On Thu, Jul 13, 2023 at 1:00 PM Rifaat Shekh-Yusef wrote: > All, > > Below is the IETF117 OAuth WG agenda. > https://datatracker.ietf.org/doc/agenda-117-oauth/ > > Take a look and let us know if you have any questions/comments. > > Regards, > Rifaat & Hannes > > > Wednesday > >- > >Chairs update – Rifaat Shekh-Yusef/Hannes Tschofenig (15 min) >- > >SD-JWT – Kristina Yasuda/Brian Campbell– (20 min) > > >https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/ >- > >Browser-based Apps – Aaron Parecki (15 min) > >https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ >- > >OAuth 2.1 – Aaron Parecki (15 min) > >https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/ >- > >Resource Server Metadata – Mike Jones (20 min) > >https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/ >- > >Cross-device flow - Pieter Kasselman (15 min) > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/ > > Thursday > >- > >JWT Embedded Tokens – Dick Hardt/Rifaat Shekh-Yusef (30 min) > >https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/ >- > >Transaction Tokens – Atul Tulshibagwale (30 min) > > > > https://datatracker.ietf.org/doc/draft-tulshibagwale-oauth-transaction-tokens/ >- > >Cross Domain Identity Chaining – Pieter Kasselman (30 min) > >https://datatracker.ietf.org/doc/draft-identity-chaining/ >- > >First party native apps - Aaron Parecki (30 min) > > > > https://datatracker.ietf.org/doc/draft-parecki-oauth-first-party-native-apps/ > > Friday > >- > >European Commission/IETF – Paolo De Rosa (30 min) >- > >SD-JWT-based Verifiable Credentials – Oliver Terbu (30 min) > >https://datatracker.ietf.org/doc/draft-terbu-oauth-sd-jwt-vc/ >- > >JWT and CWT Status List – Tobias Looker/Paul Bastian (30 min) > > >https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/ >- > >Attestation-Based Client Authentication – Tobias Looker/Paul Bastian >(30 min) > > > > https://datatracker.ietf.org/doc/draft-looker-oauth-attestation-based-client-auth/ > > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] IETF117 - OAuth WG Agenda
All, Below is the IETF117 OAuth WG agenda. https://datatracker.ietf.org/doc/agenda-117-oauth/ Take a look and let us know if you have any questions/comments. Regards, Rifaat & Hannes Wednesday - Chairs update – Rifaat Shekh-Yusef/Hannes Tschofenig (15 min) - SD-JWT – Kristina Yasuda/Brian Campbell– (20 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/ - Browser-based Apps – Aaron Parecki (15 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ - OAuth 2.1 – Aaron Parecki (15 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/ - Resource Server Metadata – Mike Jones (20 min) https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/ - Cross-device flow - Pieter Kasselman (15 min) https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/ Thursday - JWT Embedded Tokens – Dick Hardt/Rifaat Shekh-Yusef (30 min) https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/ - Transaction Tokens – Atul Tulshibagwale (30 min) https://datatracker.ietf.org/doc/draft-tulshibagwale-oauth-transaction-tokens/ - Cross Domain Identity Chaining – Pieter Kasselman (30 min) https://datatracker.ietf.org/doc/draft-identity-chaining/ - First party native apps - Aaron Parecki (30 min) https://datatracker.ietf.org/doc/draft-parecki-oauth-first-party-native-apps/ Friday - European Commission/IETF – Paolo De Rosa (30 min) - SD-JWT-based Verifiable Credentials – Oliver Terbu (30 min) https://datatracker.ietf.org/doc/draft-terbu-oauth-sd-jwt-vc/ - JWT and CWT Status List – Tobias Looker/Paul Bastian (30 min) https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/ - Attestation-Based Client Authentication – Tobias Looker/Paul Bastian (30 min) https://datatracker.ietf.org/doc/draft-looker-oauth-attestation-based-client-auth/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] IETF117 - OAuth WG call for topics
All, We have *3 official sessions* in San Francisco!!! - Wednesday 9:30-11:30 - Thursday, 13:00-15:00 - Friday 9:30-11:30 Please, let us know as soon as possible if you have topics that you would like to discuss. Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Cancelled - IETF OAuth WG Virtual Office Hours
All, The IETF OAuth WG Virtual Office Hours is cancelled for this week, because Hannes and I cannot host the call on Wednesday this week. I will later send a recurring meeting invite starting two weeks from now, because it seems that the previous invite was for one week only. Regards, Rifaat ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Invitation: IETF OAuth WG Virtual Office Hours @ Wed Jun 14, 2023 12pm - 12:30pm (EDT) (oauth@ietf.org)
All, This is the new invitation for the OAuth WG Virtual Office Hours using Zoom, because we could not resolve the issues with the IETF WebEx application. Regards, Rifaat On Wed, Jun 14, 2023 at 8:37 AM wrote: > IETF OAuth WG Virtual Office Hours > Rifaat Shekh-Yusef is inviting you to a scheduled Zoom meeting. Join Zoom > Meeting > https://us05web.zoom.us/j/83538035777?pwd=VUJmV2FVV3hUN011WjA0UWtiTE1Ddz09 > Meeting ID: 835 3803 5777 Passcode: 0wCaL > > Rifaat Shekh-Yusef is inviting you to a scheduled Zoom meeting. > > Join Zoom Meeting > https://us05web.zoom.us/j/83538035777?pwd=VUJmV2FVV3hUN011WjA0UWtiTE1Ddz09 > <https://www.google.com/url?q=https%3A%2F%2Fus05web.zoom.us%2Fj%2F83538035777%3Fpwd%3DVUJmV2FVV3hUN011WjA0UWtiTE1Ddz09&sa=D&ust=168717816000&usg=AOvVaw3k_Zh6dBufzixTznYMto0l> > > Meeting ID: 835 3803 5777 > Passcode: 0wCaLe > > WhenWednesday Jun 14, 2023 ⋅ 12pm – 12:30pm (Eastern Time - Toronto) > Location > https://us05web.zoom.us/j/83538035777?pwd=VUJmV2FVV3hUN011WjA0UWtiTE1Ddz09 > View map > <https://www.google.com/url?q=https%3A%2F%2Fus05web.zoom.us%2Fj%2F83538035777%3Fpwd%3DVUJmV2FVV3hUN011WjA0UWtiTE1Ddz09&sa=D&ust=168717816000&usg=AOvVaw3k_Zh6dBufzixTznYMto0l> > Organizer > rifaat.s.i...@gmail.com > Guests > oauth@ietf.org > View all guest info > <https://calendar.google.com/calendar/event?action=VIEW&eid=NWpjMGVxdDFkMXZwa21vaDMxZWtmOXE2Zmsgb2F1dGhAaWV0Zi5vcmc&tok=MjMjcmlmYWF0LnMuaWV0ZkBnbWFpbC5jb204Mzc4OGEyNDVjODBmMTc0MjE0MGUwNWJlOTUzODk0YzcwNjA2MmQ4&ctz=America%2FToronto&hl=en&es=0> > Reply for oauth@ietf.org > Yes > <https://calendar.google.com/calendar/event?action=RESPOND&eid=NWpjMGVxdDFkMXZwa21vaDMxZWtmOXE2Zmsgb2F1dGhAaWV0Zi5vcmc&rst=1&tok=MjMjcmlmYWF0LnMuaWV0ZkBnbWFpbC5jb204Mzc4OGEyNDVjODBmMTc0MjE0MGUwNWJlOTUzODk0YzcwNjA2MmQ4&ctz=America%2FToronto&hl=en&es=0> > No > <https://calendar.google.com/calendar/event?action=RESPOND&eid=NWpjMGVxdDFkMXZwa21vaDMxZWtmOXE2Zmsgb2F1dGhAaWV0Zi5vcmc&rst=2&tok=MjMjcmlmYWF0LnMuaWV0ZkBnbWFpbC5jb204Mzc4OGEyNDVjODBmMTc0MjE0MGUwNWJlOTUzODk0YzcwNjA2MmQ4&ctz=America%2FToronto&hl=en&es=0> > Maybe > <https://calendar.google.com/calendar/event?action=RESPOND&eid=NWpjMGVxdDFkMXZwa21vaDMxZWtmOXE2Zmsgb2F1dGhAaWV0Zi5vcmc&rst=3&tok=MjMjcmlmYWF0LnMuaWV0ZkBnbWFpbC5jb204Mzc4OGEyNDVjODBmMTc0MjE0MGUwNWJlOTUzODk0YzcwNjA2MmQ4&ctz=America%2FToronto&hl=en&es=0> > More options > <https://calendar.google.com/calendar/event?action=VIEW&eid=NWpjMGVxdDFkMXZwa21vaDMxZWtmOXE2Zmsgb2F1dGhAaWV0Zi5vcmc&tok=MjMjcmlmYWF0LnMuaWV0ZkBnbWFpbC5jb204Mzc4OGEyNDVjODBmMTc0MjE0MGUwNWJlOTUzODk0YzcwNjA2MmQ4&ctz=America%2FToronto&hl=en&es=0> > > Invitation from Google Calendar <https://calendar.google.com/calendar/> > > You are receiving this email because you are an attendee on the event. To > stop receiving future updates for this event, decline this event. > > Forwarding this invitation could allow any recipient to send a response to > the organizer, be added to the guest list, invite others regardless of > their own invitation status, or modify your RSVP. Learn more > <https://support.google.com/calendar/answer/37135#forwarding> > ___ > 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] Request for Feedback on "SD-JWT VC" Draft Specification
Thank you all for your feedback on this document. The chairs would like to make it clear that this is a call for feedback at this stage. This is *NOT* a call for adoption, because we think it is too early for that. We would like to see more feedback and discussion on the list and during the coming IETF meeting before considering adoption. Regards, Rifaat & Hannes On Wed, Jun 7, 2023 at 10:02 PM Michael Jones wrote: > Here’s some feedback based on a full read of the draft… > > > > You will eventually be asked to reference RFC 8174, like is done at > https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-16.html#name-conventions-and-terminology. > You might as well do it sooner than later. > > > > To follow the IETF draft naming conventions, you need to include the > intended working group name as the third component of the draft name. So > for instance, this draft should probably be renamed to > draft-terbu-oauth-sd-jwt-vc or draft-terbu-jose-sd-jwt-vc. > > > > In > https://www.ietf.org/archive/id/draft-terbu-sd-jwt-vc-02.html#section-4.2.2.2 > (Registered JWT Claims), I’d specify that the “iss” value must be a URL > using the “https” scheme. That way the .well-known/jwt-issuer metadata > will always be retrievable. > > > > In > https://www.ietf.org/archive/id/draft-terbu-sd-jwt-vc-02.html#section-4.2.2.2 > (Registered JWT Claims), why must the “sub” value be a URI? Are we not > interested in use cases where the “sub” references, for example, an OAuth > client, where the Client ID value is a UUID (a string)? StringOrURI seems > like a better choice. > > > > In > https://www.ietf.org/archive/id/draft-terbu-sd-jwt-vc-02.html#section-5.1 > (JWT Issuer Metadata Request), I question whether “If the iss value > contains a path component, any terminating / MUST be removed before > inserting /.well-known/ and the well-known URI suffix between the host > component and the path component.” is always the right choice. Yes, I > know that that’s what it takes to conform to RFC 5785 and I wrote similar > text at https://www.rfc-editor.org/rfc/rfc8414#section-5 , but > practically, the permissions on servers may not be administered in a way > that allows tenants to write to this location. (Yes, I plan to continue > the conversation with Mark Nottingham about allowing .well-known in > locations other than the root.) > > > > I especially like this section > https://www.ietf.org/archive/id/draft-terbu-sd-jwt-vc-02.html#name-jwt-issuer-metadata-4 > (JWT Issuer Metadata)! > > > > Hope you find this review useful… > > > >-- Mike > > > > *From:* OAuth *On Behalf Of * Oliver Terbu > *Sent:* Saturday, May 27, 2023 2:56 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Request for Feedback on "SD-JWT VC" Draft > Specification > > > > Dear all, > > I hope this email finds you well. I am writing to introduce "SD-JWT-based > Verifiable Credentials with JSON payloads” (SD-JWT VC): > > https://datatracker.ietf.org/doc/draft-terbu-sd-jwt-vc/ > > This proposal builds upon the existing SD-JWT specification by the OAuth > WG and aims to address certain gaps and provide specific guidance for > utilizing SD-JWT in the context of Verifiable Credentials. For example, > while SD-JWT defines how to implement selective disclosure in JWTs (an > important building block in many Verifiable Credential use cases), it is > not opinionated about the specific JWT Claim Sets in the payload to > represent Verifiable Credentials and used with HB-JWT. > > As you may be aware, the SD-JWT specification has already been adopted by > the OAuth WG and has gained significant traction within the industry. > However, the SD-JWT specification does not provide explicit guidance on > using SD-JWT for Verifiable Credentials. > > The eIDAS 2.0 Architecture Reference Framework (ARF) has expressed a keen > interest in utilizing SD-JWT for Verifiable Credentials, and SD-JWT VC > became one of the two core credential formats of the European Digital > Wallet (EUDIW): > > > https://github.com/eu-digital-identity-wallet/architecture-and-reference-framework > > Verifiable Credentials play a crucial role in enhancing digital trust and > enabling secure identity interactions in various domains. To ensure the > seamless integration of SD-JWT into the eIDAS ARF and similar initiatives, > it is essential to address the existing gaps in the SD-JWT specification > specifically relevant to Verifiable Credentials. > > As a general-purpose format, SD-JWT itself is not the right place to > define these kinds of guidelines. The SD-JWT VC draft proposes to fill > these gaps by defining additional requirements, clarifying ambiguities, and > providing concrete guidelines for utilizing SD-JWT in the context of > Verifiable Credentials. Since SD-JWT VC and SD-JWT are closely related, we > propose to develop this specification in the OAuth working group. > > Your support and endorsement of this proposal would significantly > cont
[OAUTH-WG] NomCom 2023 Call for Volunteers
All, *NomCom 2023* is expected to start in July and is looking for volunteers. See the following link for more information: https://mailarchive.ietf.org/arch/msg/ietf-announce/L8zEHMPqpadirzjHW8UaFvs5ZqE/ Please, consider contributing to this very important committee. Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
