[OAUTH-WG] Fwd: [Tools-discuss] Update on ongoing mail delivery issues

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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)

[Rifaat Shekh-Yusef]

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)

[Rifaat Shekh-Yusef]

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)

[Rifaat Shekh-Yusef]

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)

[Rifaat Shekh-Yusef]

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)

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

 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=05%7C02%7Cpieter.kasselman%40microsoft.com%7C357b9c804c444b4a873d08dc4e5cfea1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638471408549324339%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=l3qRXme8ywpfuSzOCxZR3VX5WbBzoLNqZJA9KrQ8r7I%3D=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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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)

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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 via Datatracker]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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 

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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

[Rifaat Shekh-Yusef]

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)

[Rifaat Shekh-Yusef]

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=D=168717816000=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=D=168717816000=AOvVaw3k_Zh6dBufzixTznYMto0l>
> Organizer
> rifaat.s.i...@gmail.com
> Guests
> oauth@ietf.org
> View all guest info
> <https://calendar.google.com/calendar/event?action=VIEW=NWpjMGVxdDFkMXZwa21vaDMxZWtmOXE2Zmsgb2F1dGhAaWV0Zi5vcmc=MjMjcmlmYWF0LnMuaWV0ZkBnbWFpbC5jb204Mzc4OGEyNDVjODBmMTc0MjE0MGUwNWJlOTUzODk0YzcwNjA2MmQ4=America%2FToronto=en=0>
> Reply for oauth@ietf.org
> Yes
> <https://calendar.google.com/calendar/event?action=RESPOND=NWpjMGVxdDFkMXZwa21vaDMxZWtmOXE2Zmsgb2F1dGhAaWV0Zi5vcmc=1=MjMjcmlmYWF0LnMuaWV0ZkBnbWFpbC5jb204Mzc4OGEyNDVjODBmMTc0MjE0MGUwNWJlOTUzODk0YzcwNjA2MmQ4=America%2FToronto=en=0>
> No
> <https://calendar.google.com/calendar/event?action=RESPOND=NWpjMGVxdDFkMXZwa21vaDMxZWtmOXE2Zmsgb2F1dGhAaWV0Zi5vcmc=2=MjMjcmlmYWF0LnMuaWV0ZkBnbWFpbC5jb204Mzc4OGEyNDVjODBmMTc0MjE0MGUwNWJlOTUzODk0YzcwNjA2MmQ4=America%2FToronto=en=0>
> Maybe
> <https://calendar.google.com/calendar/event?action=RESPOND=NWpjMGVxdDFkMXZwa21vaDMxZWtmOXE2Zmsgb2F1dGhAaWV0Zi5vcmc=3=MjMjcmlmYWF0LnMuaWV0ZkBnbWFpbC5jb204Mzc4OGEyNDVjODBmMTc0MjE0MGUwNWJlOTUzODk0YzcwNjA2MmQ4=America%2FToronto=en=0>
> More options
> <https://calendar.google.com/calendar/event?action=VIEW=NWpjMGVxdDFkMXZwa21vaDMxZWtmOXE2Zmsgb2F1dGhAaWV0Zi5vcmc=MjMjcmlmYWF0LnMuaWV0ZkBnbWFpbC5jb204Mzc4OGEyNDVjODBmMTc0MjE0MGUwNWJlOTUzODk0YzcwNjA2MmQ4=America%2FToronto=en=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

[Rifaat Shekh-Yusef]

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
> 

[OAUTH-WG] NomCom 2023 Call for Volunteers

[Rifaat Shekh-Yusef]

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

[OAUTH-WG] OAuth WG Virtual Office Hours cancelled for today

[Rifaat Shekh-Yusef]

All,

We have cancelled the OAuth WG Virtual Office Hours for today because of
the conflict with the Identiverse conference this week.

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

[OAUTH-WG] Virtual Office Hours with Meetecho

[Rifaat Shekh-Yusef]

All,

We still cannot use the IETF WebEx conference.
Let's try to use Meetecho for today's meeting:
https://meetings.conf.meetecho.com/interim/?short=eb380687-5a9d-498f-90a5-3f5d2e8d07ee

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

[OAUTH-WG] Fwd: IETF OAuth WG Virtual Office Hours

[Rifaat Shekh-Yusef]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Eastern Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Rifaat Shekh-Yusef:mailto:rifaat.shekh-yu...@ca.ey.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=rifaat.s.i
 e...@gmail.com:mailto:rifaat.s.i...@gmail.com
DESCRIPTION:\n_
 ___\nMicrosoft Teams meeting\nJoin on your computer\, mobi
 le app or room device\nClick here to join the meeting\nMeeting ID: 223 349 372 71\nPasscode: ZXyFjc\nDownload Teams | Join on the web\nJoin with a video 
 conferencing device\n971828...@t.plcm.vc\nVideo Conference ID: 117 939 011
  97\nAlternate VTC instructions\nOr call in (audio only)\n+1 647-749-1785\,\,632332623
 #   Canada\, Toronto\nPhone Conference ID:
  632 332 623#\nFind a local number | Reset PIN\n[https://cdn.ey.com/skype/ey-lo
 go-beam-tag-stacked-rgb-en.png]\nLearn More | Meeting options\n
 \n\n\nCONFIDENTIAL and
 /or PRIVILEGED. If received in error please notify the sender and permanen
 tly delete. CONFIDENTIEL et/ou PRIVILÉGIÉ. Si ce courriel est reçu par 
 erreur\, veuillez nous en aviser et en effacer toute trace. EY\, 100 Adela
 ide Street West\, PO Box 1 Toronto\, ON M5H 0B3. www.ey.com/ca To unsubscr
 ibe from commercial electronic messages / Pour vous désabonner des messag
 es électroniques commerciaux : unsubscr...@ca.ey.com\n
UID:04008200E00074C5B7101A82E00834FAFC84B87DD901000
 01B4741874F714A40A297DBB4FD4816EF
SUMMARY;LANGUAGE=en-CA:IETF OAuth WG Virtual Office Hours
DTSTART;TZID=Eastern Standard Time:20230503T12
DTEND;TZID=Eastern Standard Time:20230503T123000
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20230503T121227Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=en-CA:Microsoft Teams Meeting
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:2121604916
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-ONLINEMEETINGEXTERNALLINK:
X-MICROSOFT-ONLINEMEETINGINFORMATION:{"OnlineMeetingChannelId":null\,"Onlin
 eMeetingProvider":3}
X-MICROSOFT-ONLINEMEETINGTOLLNUMBER:+1 647-749-1785
X-MICROSOFT-ONLINEMEETINGCONFERENCEID:632332623
X-MICROSOFT-SKYPETEAMSMEETINGURL:https://teams.microsoft.com/l/meetup-join/
 19%3ameeting_YjhlMGM0MmYtZGEyMS00YjRkLWFlMDQtOTc2MzkwMmIyYmMz%40thread.v2/
 0?context=%7b%22Tid%22%3a%225b973f99-77df-4beb-b27d-aa0c70b8482c%22%2c%22O
 id%22%3a%2201aaf86a-7a18-4ca7-abf5-2ea6ebd874f0%22%7d
X-MICROSOFT-SCHEDULINGSERVICEUPDATEURL:https://api.scheduler.teams.microsof
 t.com/teams/5b973f99-77df-4beb-b27d-aa0c70b8482c/01aaf86a-7a18-4ca7-abf5-2
 ea6ebd874f0/19_meeting_YjhlMGM0MmYtZGEyMS00YjRkLWFlMDQtOTc2MzkwMmIyYmMz@th
 read.v2/0
X-MICROSOFT-SKYPETEAMSPROPERTIES:{"cid":"19:meeting_YjhlMGM0MmYtZGEyMS00YjR
 kLWFlMDQtOTc2MzkwMmIyYmMz@thread.v2"\,"rid":0\,"mid":0\,"uid":null\,"priva
 te":true\,"type":0}
X-MICROSOFT-ONLINEMEETINGCONFLINK:conf:sip:rifaat.shekh-yu...@ey.com\;gruu\
 ;opaque=app:conf:focus:id:teams:2:0!19:meeting_YjhlMGM0MmYtZGEyMS00YjRkLWF
 lMDQtOTc2MzkwMmIyYmMz-thread.v2!01aaf86a7a184ca7abf52ea6ebd874f0!5b973f997
 7df4bebb27daa0c70b8482c
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
X-MICROSOFT-LOCATIONDISPLAYNAME:Microsoft Teams Meeting
X-MICROSOFT-LOCATIONSOURCE:None
X-MICROSOFT-LOCATIONS:[{"DisplayName":"Microsoft Teams Meeting"\,"LocationA
 nnotation":""\,"LocationUri":""\,"LocationStreet":""\,"LocationCity":""\,"
 LocationState":""\,"LocationCountry":""\,"LocationPostalCode":""\,"Locatio
 nFullAddress":""}]
BEGIN:VALARM
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
OAuth mailing list

[OAUTH-WG] OAuth WG Virtual Office Hours cancelled

[Rifaat Shekh-Yusef]

All,

The OAuth WG Virtual Office Hours meeting is cancelled for today,
because we have some issues with Webex and the meeting is in conflict with
the IIW which is happening this week.

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

Re: [OAUTH-WG] OAuth WG Agenda @ IETF116

[Rifaat Shekh-Yusef]

All,

The IESG raised some concerns around the side meetings. For this reason, we
are unfortunately *canceling* these meetings at this time, and we will
discuss ways to address the IESG concerns in future meetings.

Regards,
 Rifaat & Hannes


On Tue, Mar 21, 2023 at 9:05 AM Rifaat Shekh-Yusef 
wrote:

> Yes, the side meetings time is final.
>
> Regards,
>  Rifaat
>
>
> On Tue, Mar 21, 2023 at 9:00 AM Daniel Fett  40danielfett...@dmarc.ietf.org> wrote:
>
>> Thank you, Rifaat!
>>
>> I see the side meetings listed at
>> https://wiki.ietf.org/meeting/116/sidemeetings for Wednesday and
>> Thursday, 10-11:30. Is that final?
>>
>> -Daniel
>> Am 21.03.23 um 13:35 schrieb Rifaat Shekh-Yusef:
>>
>>
>>
>> *Tuesday *
>> Chairs update – Rifaat/Hannes (10 min)
>>
>> https://datatracker.ietf.org/meeting/116/materials/slides-116-oauth-chairs-update-01
>>
>> SD-JWT – Kristina/Daniel – (20 min)
>>
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/
>>
>> Browser-based Apps – Aaron (20 min)
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/
>>
>> OAuth 2.1 – Aaron (20 min)
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
>>
>> Client/Trust Management – Kristina/Torsten (20 min)
>>
>> Protected Resource Metadata – Mike (15 min)
>> https://datatracker.ietf.org/doc/html/draft-jones-oauth-resource-metadata
>>
>> OAuth & SPIFFE – Evan/Pieter (15 min)
>> https://spiffe.io/
>>
>>
>>
>>
>> *Friday *
>> JWT Embedded Tokens – Rifaat/Dick (15 min)
>> https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/
>>
>> Cross Device Flow – Pieter (15 min)
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/
>>
>> Identity Chaining – Rifaat/Pieter (20 min)
>>
>> Native Apps UX – Aaron/Pieter (20 min)
>>
>> Authorization Server Discovery – Aaron/Ben (20 min)
>>
>> https://datatracker.ietf.org/doc/draft-parecki-oauth-authorization-server-discovery/
>>
>> PoP Security Architecture – Nat (15 min)
>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-pop-architecture
>>
>> Power of Attorney (PoA) Grant Type – Olov (15 min)
>> https://datatracker.ietf.org/doc/draft-vattaparambil-oauth-poa-grant-type/
>>
>> Regards,
>>  Rifaat & Hannes
>>
>>
>> ___
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth WG Agenda @ IETF116

[Rifaat Shekh-Yusef]

Yes, the side meetings time is final.

Regards,
 Rifaat


On Tue, Mar 21, 2023 at 9:00 AM Daniel Fett  wrote:

> Thank you, Rifaat!
>
> I see the side meetings listed at
> https://wiki.ietf.org/meeting/116/sidemeetings for Wednesday and
> Thursday, 10-11:30. Is that final?
>
> -Daniel
> Am 21.03.23 um 13:35 schrieb Rifaat Shekh-Yusef:
>
>
>
> *Tuesday *
> Chairs update – Rifaat/Hannes (10 min)
>
> https://datatracker.ietf.org/meeting/116/materials/slides-116-oauth-chairs-update-01
>
> SD-JWT – Kristina/Daniel – (20 min)
> https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/
>
> Browser-based Apps – Aaron (20 min)
> https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/
>
> OAuth 2.1 – Aaron (20 min)
> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
>
> Client/Trust Management – Kristina/Torsten (20 min)
>
> Protected Resource Metadata – Mike (15 min)
> https://datatracker.ietf.org/doc/html/draft-jones-oauth-resource-metadata
>
> OAuth & SPIFFE – Evan/Pieter (15 min)
> https://spiffe.io/
>
>
>
>
> *Friday *
> JWT Embedded Tokens – Rifaat/Dick (15 min)
> https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/
>
> Cross Device Flow – Pieter (15 min)
> https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/
>
> Identity Chaining – Rifaat/Pieter (20 min)
>
> Native Apps UX – Aaron/Pieter (20 min)
>
> Authorization Server Discovery – Aaron/Ben (20 min)
>
> https://datatracker.ietf.org/doc/draft-parecki-oauth-authorization-server-discovery/
>
> PoP Security Architecture – Nat (15 min)
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-pop-architecture
>
> Power of Attorney (PoA) Grant Type – Olov (15 min)
> https://datatracker.ietf.org/doc/draft-vattaparambil-oauth-poa-grant-type/
>
> Regards,
>  Rifaat & Hannes
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://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] OAuth WG Agenda @ IETF116

[Rifaat Shekh-Yusef]

*Tuesday*
Chairs update – Rifaat/Hannes (10 min)
https://datatracker.ietf.org/meeting/116/materials/slides-116-oauth-chairs-update-01

SD-JWT – Kristina/Daniel – (20 min)
https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/

Browser-based Apps – Aaron (20 min)
https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/

OAuth 2.1 – Aaron (20 min)
https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/

Client/Trust Management – Kristina/Torsten (20 min)

Protected Resource Metadata – Mike (15 min)
https://datatracker.ietf.org/doc/html/draft-jones-oauth-resource-metadata

OAuth & SPIFFE – Evan/Pieter (15 min)
https://spiffe.io/




*Friday*
JWT Embedded Tokens – Rifaat/Dick (15 min)
https://datatracker.ietf.org/doc/draft-yusef-oauth-nested-jwt/

Cross Device Flow – Pieter (15 min)
https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/

Identity Chaining – Rifaat/Pieter (20 min)

Native Apps UX – Aaron/Pieter (20 min)

Authorization Server Discovery – Aaron/Ben (20 min)
https://datatracker.ietf.org/doc/draft-parecki-oauth-authorization-server-discovery/

PoP Security Architecture – Nat (15 min)
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-pop-architecture

Power of Attorney (PoA) Grant Type – Olov (15 min)
https://datatracker.ietf.org/doc/draft-vattaparambil-oauth-poa-grant-type/

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

Re: [OAUTH-WG] Draft OAuth WG Agenda @ Yokohama

[Rifaat Shekh-Yusef]

Jaimandeep,

We have two side meetings at IETF116 (Wednesday and Thursday).
If you are able to work on a slide deck to discuss this topic, then we
would be happy to add that to the agenda of one of these side meetings to
allow you to present and discuss this topic.

Let us know.

Regards,
 Rifaat & Hannes


On Thu, Mar 16, 2023 at 2:15 PM Aaron Parecki  wrote:

> Hi Jaimandeep,
>
> This sounds like a good discussion to continue on the mailing list, as I
> don't think 5 minutes is enough to make any progress or come to any
> conclusions.
>
> Aaron
>
>
>
> On Thu, Mar 16, 2023 at 11:10 AM Jaimandeep Singh  40nfsu.ac...@dmarc.ietf.org> wrote:
>
>> Dear Rifaat,
>>
>> The main reason for proposing this topic was to gather the members'
>> opinions on whether the current methodology for preserving the application
>> state is adequate or there is a need to explore other alternatives. I don't
>> have any supporting documents to share at this time. My intention was
>> simply to open a discussion and assess the feasibility of alternative
>> methodologies. The topic had come up during the mailing list discussions.
>> As per my understanding, I would like to summarize the issue here:
>>
>> To ensure a better user experience, it is important to preserve the state
>> from where the OAuth process was initiated. One way to convey this
>> information is through the "state" parameter, which is passed from the
>> client to the authorization server (AS) and back. The primary purpose of
>> the "state" parameter is to mitigate Cross-Site Request Forgery (CSRF)
>> attacks, and the developers may not appreciate its use for restoring the
>> previous state of the application. The "state" parameter is impacted by all
>> the three security principles i.e confidentiality, integrity and
>> availability. The remediation measures in terms of confidentiality and
>> integrity have been well brought out by the members in the mailing list by
>> way of encryption or signing of "state" parameters. However, decryption and
>> verification of the "state" parameter incurs performance penalties.
>> Therefore, two questions arise:
>> (a) Are there any other patterns that we can look at to address the
>> concerns in terms of performance penalty?
>> (b) Is there a need to provide clear guidelines on how to restore the
>> previous state of the client application to ensure a seamless user
>> experience in upcoming RFCs?
>>
>> Regards
>> Jaimandeep Singh
>>
>>
>>
>> On Thu, Mar 16, 2023 at 5:39 PM Rifaat Shekh-Yusef <
>> rifaat.s.i...@gmail.com> wrote:
>>
>>> Hi Jaimandeep,
>>>
>>> Can you elaborate on bullet 3? Do you have a document that discusses
>>> this topic?
>>>
>>> Regards,
>>>  Rifaat
>>>
>>>
>>> On Thu, Mar 16, 2023 at 2:01 AM Jaimandeep Singh <
>>> jaimandeep.phdc...@nfsu.ac.in> wrote:
>>>
>>>> Dear Rifaat,
>>>>
>>>> I would like to suggest following regarding the upcoming conference:
>>>>
>>>> 1. It would be very beneficial if the presenters could share the
>>>> presentation materials and discussion points for each item on the agenda
>>>> well in advance. This would enable us to go through the same and streamline
>>>> the discussion. IMO when the points for discussion are presented at the
>>>> last moment, it is difficult to make meaningful contributions.
>>>>
>>>> 2. Additionally, I suggest that we establish a hard cutoff time for
>>>> each agenda item to ensure that we cover all the items on the agenda within
>>>> the allocated time. In case of time overrun, we can continue the same in
>>>> side discussions. In the last conference, it was observed that some agenda
>>>> points ran over time, which meant that other important items on agenda were
>>>> not addressed or did not get sufficient time.
>>>>
>>>> 3. If the members agree, a 5-minute agenda item can be added to discuss
>>>> the use of the "state" parameter design pattern for preserving the current
>>>> state and the impact it may have on performance of the oauth.
>>>>
>>>> Regards
>>>> Jaimandeep Singh
>>>>
>>>> On Wed, 15 Mar, 2023, 7:34 pm Rifaat Shekh-Yusef, <
>>>> rifaat.s.i...@gmail.com> wrote:
>>>>
>>>>> All,
>>>>>
>>>>> The following is the agenda for the official two sessi

Re: [OAUTH-WG] Draft OAuth WG Agenda @ Yokohama

[Rifaat Shekh-Yusef]

Hi Jaimandeep,

Can you elaborate on bullet 3? Do you have a document that discusses this
topic?

Regards,
 Rifaat


On Thu, Mar 16, 2023 at 2:01 AM Jaimandeep Singh <
jaimandeep.phdc...@nfsu.ac.in> wrote:

> Dear Rifaat,
>
> I would like to suggest following regarding the upcoming conference:
>
> 1. It would be very beneficial if the presenters could share the
> presentation materials and discussion points for each item on the agenda
> well in advance. This would enable us to go through the same and streamline
> the discussion. IMO when the points for discussion are presented at the
> last moment, it is difficult to make meaningful contributions.
>
> 2. Additionally, I suggest that we establish a hard cutoff time for each
> agenda item to ensure that we cover all the items on the agenda within the
> allocated time. In case of time overrun, we can continue the same in side
> discussions. In the last conference, it was observed that some agenda
> points ran over time, which meant that other important items on agenda were
> not addressed or did not get sufficient time.
>
> 3. If the members agree, a 5-minute agenda item can be added to discuss
> the use of the "state" parameter design pattern for preserving the current
> state and the impact it may have on performance of the oauth.
>
> Regards
> Jaimandeep Singh
>
> On Wed, 15 Mar, 2023, 7:34 pm Rifaat Shekh-Yusef, 
> wrote:
>
>> All,
>>
>> The following is the agenda for the official two sessions scheduled for
>> the OAuth WG:
>>
>> *Tuesday*
>>
>>- *Chairs update –* Rifaat/Hannes (10 min)
>>- *SD-JWT *– Kristina/Daniel – (20 min)
>>- *Browser-based Apps* – Aaron (20 min)
>>- *OAuth 2.1* – Aaron (20 min)
>>- *Client/Trust Management *– Kristina/Torsten (20 min)
>>- *Protected Resource Metadata *– Mike (15 min)
>>- *Machine Identity *– Pieter (15 min)
>>
>>
>> *Friday*
>>
>>- *JWT Embedded Tokens *– Rifaat/Dick (15 min)
>>- *Cross Device Flow –* Pieter (15 min)
>>- *Identity Chaining *– Rifaat/Pieter (20 min)
>>- *Native Apps UX* – Aaron/Pieter (20 min)
>>- *Authorization Server Discovery *– Aaron/Ben (20 min)
>>- *PoP Security Architecture *– Nat (15 min)
>>- *Power of Attorney (PoA) Grant Type *– Olov (15 min)
>>
>>
>> Please, let us know if you have any comments about the above agenda.
>>
>> 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] Draft OAuth WG Agenda @ Yokohama

[Rifaat Shekh-Yusef]

All,

The following is the agenda for the official two sessions scheduled for the
OAuth WG:

*Tuesday*

   - *Chairs update –* Rifaat/Hannes (10 min)
   - *SD-JWT *– Kristina/Daniel – (20 min)
   - *Browser-based Apps* – Aaron (20 min)
   - *OAuth 2.1* – Aaron (20 min)
   - *Client/Trust Management *– Kristina/Torsten (20 min)
   - *Protected Resource Metadata *– Mike (15 min)
   - *Machine Identity *– Pieter (15 min)


*Friday*

   - *JWT Embedded Tokens *– Rifaat/Dick (15 min)
   - *Cross Device Flow –* Pieter (15 min)
   - *Identity Chaining *– Rifaat/Pieter (20 min)
   - *Native Apps UX* – Aaron/Pieter (20 min)
   - *Authorization Server Discovery *– Aaron/Ben (20 min)
   - *PoP Security Architecture *– Nat (15 min)
   - *Power of Attorney (PoA) Grant Type *– Olov (15 min)


Please, let us know if you have any comments about the above agenda.

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

Re: [OAUTH-WG] IETF 116 Preliminary Agenda

[Rifaat Shekh-Yusef]

We have also scheduled two *side meetings *on Wednesday and Thursday,
10:00-11:30 at G301 room.

Regards,
 Rifaat

On Fri, Feb 24, 2023 at 6:01 PM Rifaat Shekh-Yusef 
wrote:

> Based on the preliminary agenda, we have two official sessions:
> *Tuesday *and *Friday*, both at *9:30-11:30*.
>
> Regards,
>  Rifaat
>
>
> -- Forwarded message -
> From: IETF Agenda 
> Date: Fri, Feb 24, 2023 at 5:50 PM
> Subject: IETF 116 Preliminary Agenda
> To: IETF Announcement List 
> Cc: , <116...@ietf.org>
>
>
> IETF 116
> Yokohama, Japan
> March 25-31, 2023
> Hosted By: WIDE
>
>
> The IETF 116 Preliminary Agenda has been posted. The final agenda will be
> published on Friday, March 3, 2023.
>
> https://datatracker.ietf.org/meeting/116/agenda.html
> https://datatracker.ietf.org/meeting/116/agenda.txt
>
> The preliminary agenda includes all planned WG, RG, and BoF sessions.
> Information about side meetings will be available when the final agenda is
> posted.
>
> IETF 116 Information: https://www.ietf.org/how/meetings/116/
> Register online at: https://registration.ietf.org/116/
>
> Don’t forget to register for these exciting IETF 116 events!
>
>
> Social Event
>
> The Osanbashi Pier's multipurpose hall will be transformed into a
> wonderful social event location for IETF 116 attendees in Yokohama.
>
> Attendees will be delighted by the music of internationally renowned
> artist Kaoru Watanabe, delicious food and a Japanese sake corner
> introducing attendees to sake from all thirteen sake breweries in Kanagawa
> Prefecture.
>
> - Date: Thursday, March 30
>
> - Start/End Times: 19:00 – 21:30
>
> - Cost per ticket: $25 per ticket
>
> - Limit of tickets per attendee: Two per attendee.
>
> More information:
> https://www.ietf.org/how/meetings/116/social/
> https://ietf116.jp/social-event/
>
>
> Hackathon
>
> Onsite signup: https://registration.ietf.org/116/new/hackathon_onsite/
> Remote signup: https://registration.ietf.org/116/new/hackathon_remote/
> More information:
> https://www.ietf.org/how/runningcode/hackathons/116-hackathon/
> Keep up to date by subscribing to:
> https://www.ietf.org/mailman/listinfo/hackathon
>
>
> Code Sprint
>
> More information and signups: https://notes.ietf.org/notes-ietf-116-tools#
>
> ___
> 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] Fwd: IETF 116 Preliminary Agenda

[Rifaat Shekh-Yusef]

Based on the preliminary agenda, we have two official sessions:
*Tuesday *and *Friday*, both at *9:30-11:30*.

Regards,
 Rifaat


-- Forwarded message -
From: IETF Agenda 
Date: Fri, Feb 24, 2023 at 5:50 PM
Subject: IETF 116 Preliminary Agenda
To: IETF Announcement List 
Cc: , <116...@ietf.org>


IETF 116
Yokohama, Japan
March 25-31, 2023
Hosted By: WIDE


The IETF 116 Preliminary Agenda has been posted. The final agenda will be
published on Friday, March 3, 2023.

https://datatracker.ietf.org/meeting/116/agenda.html
https://datatracker.ietf.org/meeting/116/agenda.txt

The preliminary agenda includes all planned WG, RG, and BoF sessions.
Information about side meetings will be available when the final agenda is
posted.

IETF 116 Information: https://www.ietf.org/how/meetings/116/
Register online at: https://registration.ietf.org/116/

Don’t forget to register for these exciting IETF 116 events!


Social Event

The Osanbashi Pier's multipurpose hall will be transformed into a wonderful
social event location for IETF 116 attendees in Yokohama.

Attendees will be delighted by the music of internationally renowned artist
Kaoru Watanabe, delicious food and a Japanese sake corner introducing
attendees to sake from all thirteen sake breweries in Kanagawa Prefecture.

- Date: Thursday, March 30

- Start/End Times: 19:00 – 21:30

- Cost per ticket: $25 per ticket

- Limit of tickets per attendee: Two per attendee.

More information:
https://www.ietf.org/how/meetings/116/social/
https://ietf116.jp/social-event/


Hackathon

Onsite signup: https://registration.ietf.org/116/new/hackathon_onsite/
Remote signup: https://registration.ietf.org/116/new/hackathon_remote/
More information:
https://www.ietf.org/how/runningcode/hackathons/116-hackathon/
Keep up to date by subscribing to:
https://www.ietf.org/mailman/listinfo/hackathon


Code Sprint

More information and signups: https://notes.ietf.org/notes-ietf-116-tools#

___
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

Re: [OAUTH-WG] IETF-116: Client/Trust Management

[Rifaat Shekh-Yusef]

Hi Torsten,

Sounds good. I will add this topic to the list.

Regards,
 Rifaat


On Tue, Jan 31, 2023 at 11:18 AM Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

> Hi Rifaat,
>
> Kristina and I would like to give an update to the WG about challenges and
> developments on client/trust management in the context of decentralized
> identity at IETF-116.  We would seek the WG's feedback on our current ideas
> how to cope with them. We also think some of the ideas could be leveraged
> in other OAuth applications.
>
> This is a continuation of the session Kristian and Tobias held at the last
> meeting.
>
> 20 min would be much appreciated.
>
> best regards,
> Torsten.
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAUTH for Web Proxy authentication

[Rifaat Shekh-Yusef]

Hi Markus,

As Goerge mentioned, there is no such document that covers this.
What use case(s) do you have in mind for this?

Regards,
 Rifaat


On Sat, Jan 28, 2023 at 7:50 PM Markus  wrote:

> Thank you.
>
> Regards
> Markus
> *From:* George Fletcher
> *Sent:* Saturday, January 28, 2023 1:43 PM
> *To:* Markus; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] OAUTH for Web Proxy authentication
>
> To my knowledge that spec doesn't exist. I'll let others chime in if they
> have seen a proposal in that regard.
>
> In regards to which working group, given the core topic is OAuth
> authorization, I would present it here at a minimum.
>
> Thanks,
> George
>
> On 1/22/23 7:06 AM, Markus PlusNet wrote:
>
> Dear WG,
>
> I am new to oauth and wonder which WG would be responsible for
> reviewing a Spec for Proxy authentication
> https://httpwg.org/specs/rfc9110.html#auth.client.proxy using oauth or
> does that spec already exist ?
>
> Thank you
> Markus
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Protected Resource Metadata

[Rifaat Shekh-Yusef]

I added both to the list of topics to discuss in Yokohama.
Let's have that discussion first, before calling for any adoption.

Regards,
 Rifaat & Hannes


On Sat, Jan 28, 2023 at 8:35 PM Aaron Parecki  wrote:

> There is significant overlap between this draft and the concepts brought
> to the OAuth WG at the last IETF meeting by Ben Schwartz, which he also
> presented to the HTTPAPI WG. After that meeting, I volunteered to work with
> Ben on adapting his concepts to a model that would fit better within the
> OAuth framework. I published an early draft, which I am planning on
> presenting at the next IETF meeting.
> https://datatracker.ietf.org/doc/draft-parecki-oauth-authorization-server-discovery/
>
> During the HTTPAPI and OAuth sessions at IETF 115, there were many
> concerns expressed by various people in the groups about establishing and
> enabling this kind of relationship, which would also apply to this Resource
> Metadata draft. I believe there should be further discussions about the
> concepts described here as well as how best to enable other working groups
> to take advantage of this kind of relationship between an RS and AS before
> adopting this particular draft.
>
> Aaron
>
>
>
> On Sat, Jan 28, 2023 at 5:21 PM David Waite  40alkaline-solutions@dmarc.ietf.org> wrote:
>
>> I support adoption by the working group.
>>
>> -DW
>>
>> On Jan 24, 2023, at 2:38 AM, Giuseppe De Marco 
>> wrote:
>>
>> Hello everybody,
>>
>> I would like to bring to your attention this expired draft:
>> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>>
>> I propose the take up this individual draft for its adoption as an
>> official internet draft.
>> The reason I ask this is that there are implementations of this draft
>> born with the need to have metadata for entities of type RS.
>>
>> The implementation of which I am aware concerns the Italian "Attribute
>> Authorities" [0]. OpenID Federation draft also defines the metadata of the
>> oauth_resource type [1], taking up the elements defined in the draft in
>> question. Recently, an interesting reflection seems to have arisen also in
>> OpenID4VCI/OpenID4VP [2].
>>
>> Thank you for your attention, I hope to read your valuable feedback soon,
>> best
>>
>> [0] https://italia.github.io/spid-cie-oidc-docs/en/metadata_aa.html
>> [1]
>> https://openid.net/specs/openid-connect-federation-1_0.html#section-4.7
>> [2]
>> https://bitbucket.org/openid/connect/issues/1781/do-new-entity-types-required-for-oid4vp
>>
>> ___
>> 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

Re: [OAUTH-WG] Implementations - OAuth 2.0 Step-up Authentication Challenge Protocol

[Rifaat Shekh-Yusef]

Thanks Brock!

I added this implementation to the shepherd writeup.

Regards,
 Rifaat


On Fri, Jan 20, 2023 at 12:29 AM Vittorio Bertocci <
vittorio.berto...@auth0.com> wrote:

> Wonderful, thanks Brock!
>
> On Thu, Jan 19, 2023 at 14:55 Brock Allen  wrote:
>
>> *This message originated outside your organization.*
>>
>> --
>>
>> The current version of Duende IdentityServer supports everything included
>> in this proposal, except for the new unmet_authentication_requirement
>> error which has been added for v6.3.0 being released this summer.
>>
>> https://duendesoftware.com/
>> <https://urldefense.com/v3/__https://duendesoftware.com/__;!!PwKahg!_QqcL9hmzoBR8DK13nAEH18tSGzXNWCtB-fwB994SSlW5a9xTT07XjbAovAQZ6R6ywOpY_LdQCFxbnCkRFA$>
>>
>> Thanks.
>>
>>
>> -Brock
>>
>> On 12/20/2022 8:15:52 AM, Rifaat Shekh-Yusef 
>> wrote:
>> All,
>>
>> As part of the shepherd write-up for the OAuth 2.0 Step-up Authentication
>> Challenge Protocol document,
>> we are looking for information about implementations of this draft.
>>
>>
>> https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-08.html
>> <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-08.html__;!!PwKahg!_QqcL9hmzoBR8DK13nAEH18tSGzXNWCtB-fwB994SSlW5a9xTT07XjbAovAQZ6R6ywOpY_LdQCFxnos_V5w$>
>>
>> Please, reply to this email, on the mailing list, with any
>> implementations that you are aware of to support this document.
>>
>> Regards,
>> Rifaat
>> ___ OAuth mailing list
>> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!_QqcL9hmzoBR8DK13nAEH18tSGzXNWCtB-fwB994SSlW5a9xTT07XjbAovAQZ6R6ywOpY_LdQCFxc2F1lsE$>
>>
>> ___
>> 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] Publication has been requested for draft-ietf-oauth-step-up-authn-challenge-08

[Rifaat Shekh-Yusef via Datatracker]

Rifaat Shekh-Yusef has requested publication of 
draft-ietf-oauth-step-up-authn-challenge-08 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-step-up-authn-challenge/


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

[OAUTH-WG] OAuth WG Virtual Office Hours is cancelled for today

[Rifaat Shekh-Yusef]

All,

Because of the holidays, the OAuth WG Virtual Office Hours is cancelled for
today.

Happy holidays!

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

[OAUTH-WG] JWT Embedded Tokens

[Rifaat Shekh-Yusef]

All,

Dick, Giuseppe, and I submitted a new version of JWT Embedded Tokens
(previously known as Multi-Subject JWT).
https://www.ietf.org/archive/id/draft-yusef-oauth-nested-jwt-06.html

We would appreciate any feedback on this document.

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

Re: [OAUTH-WG] Implementations - OAuth 2.0 Step-up Authentication Challenge Protocol

[Rifaat Shekh-Yusef]

Thanks Takahiko!

On Wed, Dec 21, 2022 at 4:33 PM Takahiko Kawasaki  wrote:

> Hi Rifaat,
>
> Authlete 2.3, which is planned to be released next month (January 2023),
> supports OAuth 2.0 Step-up Authentication Challenge Protocol. I've
> published an article on Authlete's website that explains the specification
> in detail with many diagrams.
>
> OAuth 2.0 Step-up Authentication Challenge Protocol
> https://www.authlete.com/developers/stepup_authn/
>
> Best Regards,
> Takahiko Kawasaki
>
>
> On Tue, Dec 20, 2022 at 10:15 PM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
>> All,
>>
>> As part of the shepherd write-up for the OAuth 2.0 Step-up Authentication
>> Challenge Protocol document,
>> we are looking for information about implementations of this draft.
>>
>>
>> https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-08.html
>>
>> Please, reply to this email, on the mailing list, with any
>> implementations that you are aware of to support this document.
>>
>> Regards,
>> Rifaat
>> ___
>> 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] Implementations - OAuth 2.0 Step-up Authentication Challenge Protocol

[Rifaat Shekh-Yusef]

Thanks, Brian!

On Tue, Dec 20, 2022 at 3:52 PM Brian Campbell 
wrote:

> It's just an aspect of generally flexible/configurable products so there
> aren't documents that specifically call out support. That I'm aware of
> anyway. I'm admittedly not terribly familiar with our documentation. But I
> found a couple things. LIke this
> https://docs.pingidentity.com/r/en-us/pingaccess-71/mhu1564006734179 is
> about configuring related policy at a resource server. And this
> https://docs.pingidentity.com/r/en-us/pingfederate-112/pf_authoriz_endpoint
> notes the max_age and acr_values parameters at the authorization endpoint.
>
>
>
> On Tue, Dec 20, 2022 at 6:44 AM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
>> Thanks Brian!
>>
>> Any links to public documents that cover this that you could share?
>>
>> Thanks,
>>  Rifaat
>>
>>
>> On Tue, Dec 20, 2022 at 8:39 AM Brian Campbell <
>> bcampb...@pingidentity.com> wrote:
>>
>>> Ping Identity has implementations of the functionality in this document
>>> for the authorization server and resource server roles.
>>>
>>> On Tue, Dec 20, 2022 at 6:16 AM Rifaat Shekh-Yusef <
>>> rifaat.s.i...@gmail.com> wrote:
>>>
>>>> All,
>>>>
>>>> As part of the shepherd write-up for the OAuth 2.0 Step-up
>>>> Authentication Challenge Protocol document,
>>>> we are looking for information about implementations of this draft.
>>>>
>>>>
>>>> https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-08.html
>>>>
>>>> Please, reply to this email, on the mailing list, with any
>>>> implementations that you are aware of to support this document.
>>>>
>>>> Regards,
>>>> Rifaat
>>>> ___
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>> privileged material for the sole use of the intended recipient(s). Any
>>> review, use, distribution or disclosure by others is strictly prohibited.
>>> If you have received this communication in error, please notify the sender
>>> immediately by e-mail and delete the message and any file attachments from
>>> your computer. Thank you.*
>>
>>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Implementations - OAuth 2.0 Step-up Authentication Challenge Protocol

[Rifaat Shekh-Yusef]

Thanks Brian!

Any links to public documents that cover this that you could share?

Thanks,
 Rifaat


On Tue, Dec 20, 2022 at 8:39 AM Brian Campbell 
wrote:

> Ping Identity has implementations of the functionality in this document
> for the authorization server and resource server roles.
>
> On Tue, Dec 20, 2022 at 6:16 AM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
>> All,
>>
>> As part of the shepherd write-up for the OAuth 2.0 Step-up Authentication
>> Challenge Protocol document,
>> we are looking for information about implementations of this draft.
>>
>>
>> https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-08.html
>>
>> Please, reply to this email, on the mailing list, with any
>> implementations that you are aware of to support this document.
>>
>> Regards,
>> Rifaat
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Implementations - OAuth 2.0 Step-up Authentication Challenge Protocol

[Rifaat Shekh-Yusef]

All,

As part of the shepherd write-up for the OAuth 2.0 Step-up Authentication
Challenge Protocol document,
we are looking for information about implementations of this draft.

https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-08.html

Please, reply to this email, on the mailing list, with any implementations
that you are aware of to support this document.

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

[OAUTH-WG] IPR Disclosure - OAuth 2.0 Step-up Authentication Challenge Protocol

[Rifaat Shekh-Yusef]

Authors,

As part of the shepherd write-up, all authors of OAuth 2.0 Step-up
Authentication Challenge Protocol
must confirm that any and all appropriate IPR disclosures required for full
conformance with the provisions
of BCP 78 and BCP 79 have been filed.

https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-08.html

Please, reply to this email, 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
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Step-up Authentication Shepherd Review

[Rifaat Shekh-Yusef]

On Mon, Dec 19, 2022 at 4:40 PM Brian Campbell 
wrote:

> Hi Rifaat,
>
> I certainly didn't expect a response over the weekend.  Apologies if the
> timing of my message (late afternoon Friday my timezone) unintentionally
> encouraged weekend work. But with that said, my attempt at a reply is
> below.
>
> No worries :)



> On Sun, Dec 18, 2022 at 1:42 PM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
>>
>> On Fri, Dec 16, 2022 at 5:50 PM Brian Campbell <
>> bcampb...@pingidentity.com> wrote:
>>
>>>
>>> On Tue, Dec 13, 2022 at 2:58 PM Rifaat Shekh-Yusef <
>>> rifaat.s.i...@gmail.com> wrote:
>>>
>>>
>>>
>>>> * Section 5
>>>>
>>>> “when it comes to access tokens in this specification it is RECOMMENDED
>>>> that the requested acr value is treated as required”
>>>>
>>>> Not sure why this sentence started in such a way. Why not just
>>>> explicitly use MUST to make sure that the acr value is included in the
>>>> access token?
>>>>
>>>
>>> The rest of Section 5 tries to put that into context better but
>>> basically OIDC suggests that a successful auth response be sent when the
>>> requested acr can't be satisfied but it does allow the AS to respond with
>>> an error auth response. This draft wants to nudge the other way and
>>> suggest that an error auth response be sent when the requested acr
>>> can't be satisfied but still allow for the OIDC suggested behavior.
>>> It's a bit of a fine line. But that's the aim. Furthermore, I do think it's
>>> appropriate to always allow authorization servers some latitude in handling
>>> the auth request with success or failure as there may be other things that
>>> come into play during the user authentication and approval interactions.
>>>
>>>
>>>
>> I get that, but I am having a hard time with a sentence that states
>> *RECOMMENDED* and *required* at the same time.
>>
> Maybe a SHOULD is more appropriate then?
>>
>
> Per RFC2119 sec 3 <https://www.rfc-editor.org/rfc/rfc2119.html#section-3>,
> SHOULD and RECOMMENDED are basically stating the same level of requirement.
> And required itself isn't a normative keyword. So I don't think there's a
> contradiction here. But perhaps using SHOULD and tweaking a few words would
> make the sentence more easily digested? Or maybe I'm misunderstanding? I do
> get the feeling we've maybe been talking past one another. But I'm going to
> stop speculating and just propose this updated language for that sentence
> to see if we can move forward:
>
> "Although [OIDC
> <https://www.ietf.org/archive/id/draft-bertocci-oauth-step-up-authn-challenge-01.html#OIDC>
> ] leaves the authorization server free to decide how to handle the
> inclusion of acr in ID Token when requested via acr_values, when it comes
> to access tokens in this specification, the authorization server SHOULD
> consider the requested acr value as necessary for successfully fulfilling
> the request."
>
> Does that text work better for you and/or allay the concern?
>

Yes, this does address my comment, and it feels clearer to me at least 

Feel free to submit a new version with the updated text, and I will then
start working on the document shepherd write-up.

Regards,
 Rifaat






>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Step-up Authentication Shepherd Review

[Rifaat Shekh-Yusef]

On Fri, Dec 16, 2022 at 5:50 PM Brian Campbell 
wrote:

> Thanks for the review and shepherding Rifaat,
>
> Please see inline below where I've endeavored to reply to your comments. A
> -07 draft with the respective changes is forthcoming.
>
>
> On Tue, Dec 13, 2022 at 2:58 PM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
>> Vittorio, Brian,
>>
>> The following is my document shepherd review for the step-up
>> authentication document:
>>
>> https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-06.html
>>
>>
>> *Comments*
>>
>> * Section 4, first sentence:
>>
>>
>> You might have a reason for using MAY, instead of SHOULD, but it is not
>> obvious to me. Can you add some text to explain the reason for this?
>>
>
> Looking at it again, I think I concur with you and also think it should be
> a SHOULD. I'll change it as such. I believe the reason behind the MAY
> originally was trying to convey that a client is never obligated to act on
> receiving a challenge by sending an authorization request. But that text
> has more going on that muddies it somewhat and a SHOULD still allows for it
> and would be more appropriate there anyway.
>
>
>
>
>> * Section 5
>>
>> “when it comes to access tokens in this specification it is RECOMMENDED
>> that the requested acr value is treated as required”
>>
>> Not sure why this sentence started in such a way. Why not just explicitly
>> use MUST to make sure that the acr value is included in the access token?
>>
>
> The rest of Section 5 tries to put that into context better but basically
> OIDC suggests that a successful auth response be sent when the requested
> acr can't be satisfied but it does allow the AS to respond with an error auth
> response. This draft wants to nudge the other way and suggest that an
> error auth response be sent when the requested acr can't be satisfied but
> still allow for the OIDC suggested behavior. It's a bit of a fine line.
> But that's the aim. Furthermore, I do think it's appropriate to always
> allow authorization servers some latitude in handling the auth request with
> success or failure as there may be other things that come into play during
> the user authentication and approval interactions.
>
>
I get that, but I am having a hard time with a sentence that states
*RECOMMENDED* and *required* at the same time. Maybe a SHOULD is more
appropriate then?

Regards,
 Rifaar


>
>
>> * Section 9, last sentence
>>
>> I think we need to have a stronger statement here and not leave it wide
>> open like this.
>>
>> Maybe state that the resource server SHOULD NOT return a challenge if the
>> request did not include a valid token?
>>
>
> I'd suggest that there are legit cases where either behavior would be
> okay and perfectly appropriate. We are pointing out the potential
> implications/tradeoffs, which is appropriate for this in the
> considerations. And allows RSs to do what is best for their situation
> having been informed of those considerations.
>
>
>
> *Nits*
>>
>> Section 2 - “not be necessarily hold true” -> drop the “be”
>>
>> Section 5 - Thee - > The
>>
>> Section 8 - any undesirable -> an undesirable
>>
>> Section 9 - {#Challenge} -> fix the reference
>>
>
> Thanks for catching these. Will fix 'em all.
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Step-up Authentication Shepherd Review

[Rifaat Shekh-Yusef]

Vittorio, Brian,

The following is my document shepherd review for the step-up
authentication document:
https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-06.html


*Comments*

* Section 4, first sentence:


You might have a reason for using MAY, instead of SHOULD, but it is not
obvious to me. Can you add some text to explain the reason for this?


* Section 5

“when it comes to access tokens in this specification it is RECOMMENDED
that the requested acr value is treated as required”

Not sure why this sentence started in such a way. Why not just explicitly
use MUST to make sure that the acr value is included in the access token?


* Section 9, last sentence

I think we need to have a stronger statement here and not leave it wide
open like this.

Maybe state that the resource server SHOULD NOT return a challenge if the
request did not include a valid token?


*Nits*

Section 2 - “not be necessarily hold true” -> drop the “be”

Section 5 - Thee - > The

Section 8 - any undesirable -> an undesirable

Section 9 - {#Challenge} -> fix the reference


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

Re: [OAUTH-WG] Call for adoption: Cross-Device Flows

[Rifaat Shekh-Yusef]

All,

Based on the feedback during the meeting in London, and on the mailing
list, the WG has decided to adopt this draft as a WG document.


Authors,

Please, submit a WG -00 version of the document at your earliest
convenience.

Regards,
 Rifaat & Hannes



On Wed, Nov 23, 2022 at 3:03 AM Daniel Fett  wrote:

> I support adoption of this document.
>
> -Daniel
> Am 15.11.22 um 15:43 schrieb Rifaat Shekh-Yusef:
>
> All,
>
> During the IETF meeting last week, there was a strong support for
> the adoption of the following document as a WG document:
> https://datatracker.ietf.org/doc/draft-kasselman-cross-device-security/
>
> This is to start a call for adoption for this document.
> Please, provide your feedback on the mailing list on whether you support
> the adoption of this document as a WG or not, by *Nov 29th*.
>
> Regards,
>  Rifaat & Hannes
>
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Tuesday side meeting agenda

[Rifaat Shekh-Yusef]

Hi Kai,

These slides are already on the OAuth WG meeting material.
I have added the links to the two related presentations:
https://datatracker.ietf.org/meeting/115/materials/slides-115-oauth-fine-grained-transactional-authorization-sgnl-proposal
https://datatracker.ietf.org/meeting/115/materials/slides-115-oauth-identity-chaining-using-oauth-token-exchange

Regards,
 Rifaat




On Wed, Nov 16, 2022 at 2:37 AM Kai Lehmann  wrote:

> Hi Rifaat,
>
>
>
> the ones regarding the Fine Grained Authorization discussion.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From: *Rifaat Shekh-Yusef 
> *Date: *Tuesday, 15. November 2022 at 20:45
> *To: *Kai Lehmann 
> *Cc: *oauth 
> *Subject: *Re: [OAUTH-WG] Tuesday side meeting agenda
>
>
>
> Hi Kai,
>
>
>
> Unfortunately, we did not take notes for these meetings.
>
> Which slides specifically are you referring to?
>
>
>
> Regards,
>
>  Rifaat
>
>
>
>
>
> On Tue, Nov 15, 2022 at 4:14 AM Kai Lehmann  wrote:
>
> Hi Rifaat,
>
>
>
> are the slides/meeting notes available for the side meetings somewhere?
> There have been some slides shown and discussed during the side-meeting on
> Thursday and I would like to revisit them. If there are slides/notes
> available, it might be a good idea to reference them here:
>
>
>
> https://wiki.ietf.org/meeting/115/sidemeetings
>
>
>
> Thanks,
>
> Kai
>
>
>
>
>
> *From: *OAuth  on behalf of Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com>
> *Date: *Tuesday, 15. November 2022 at 00:44
> *To: *Dmitry Telegin 
> *Cc: *oauth 
> *Subject: *Re: [OAUTH-WG] Tuesday side meeting agenda
>
>
>
> Hi Dmitry,
>
>
>
> Unfortunately, the side meetings are not recorded.
>
>
>
> Regards,
>
>  Rifaat
>
>
>
> On Monday, November 14, 2022, Dmitry Telegin  wrote:
>
> Hello Rifaat,
>
>
>
> Are there plans to publish side meetings agendas/slides/recordings, for
> those who didn't manage to attend?
>
>
>
> Thanks,
>
> Dmitry
>
>
>
> On Tue, Nov 8, 2022 at 11:16 AM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
> The side meeting is at 2:00pm at Richmond 6.
>
>
>
> Regards,
>
>  Rifaat
>
>
>
>
>
> On Tue, Nov 8, 2022 at 10:14 AM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
> All,
>
>
>
> The agenda for today's side meeting is the following:
>
> 1. WG Github, OAuth 2.1/Browser-based App - 30 minutes
>
> 2. DPoP - AD and FAPI feedback - 30 minutes
>
>
>
> We only have 1 hour today because of a conflict with the COSE WG.
>
>
>
> Regards,
>
>  Rifaat
>
>
>
> ___
> 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 Virtual Office Hours is cancelled for today

[Rifaat Shekh-Yusef]

All,

Hannes and I have a conflict today, and we will not be able to host
the OAuth WG Virtual Office Hours meeting.

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