Re: [OAUTH-WG] BCP: Mix-Up Attacks, Implicit Grant Variant

[Aaron Parecki]

Hi Warren, this is described in detail in the linked paper on page 31 if
you need further clarification.

Aaron


On Wed, Jun 14, 2023 at 7:36 AM Warren Parad  wrote:

> That doesn't make sense to me.
>
> On Wed, Jun 14, 2023, 21:31 Daniel Fett  40danielfett...@dmarc.ietf.org> wrote:
>
>> Hi Alexander,
>> Am 14.06.23 um 15:19 schrieb Alexander Rademann:
>>
>> *Hello, everyone! Section 4.4.1 of the BCP
>> 
>> draft lists several variants of mix-up attacks; the description of the
>> Implicit grant variant reads as follows: "In the implicit grant, the
>> attacker receives an access token instead of the code; the rest of the
>> attack works as above." Given the attack description in that section, it is
>> not clear to me why an attacker would receive the access token and which
>> part the "rest of the attack" refers to. When the Implicit grant is used,
>> H-AS sends the access token (via redirect) to the user agent, which
>> extracts it and sends it to the client. However, the client does not send
>> the access token to A-AS, does it? (I hope that I didn’t overlook anything
>> in that section.)*
>>
>> * I also checked the referenced paper ;
>> there, the authors assume that the access token is sent to the
>> authorization server under the control of the attacker (or, using their
>> terminology, identity provider) to access some resource. [Appendix B, p.
>> 31ff] Perhaps this (or some similar) assumption should be added to the
>> description of this variant?*
>>
>> The underlying assumption is that when then user selected to use A-AS in
>> the beginning, the access token would also be used with a Resource Server
>> under the attacker's control.
>>
>> -Daniel
>>
>>
>> * I'm sorry if I missed anything or if this has already been addressed
>> before, I'm new to this mailing list and did not find anything in the
>> archives. Kind regardsAlex*
>>
>> ___
>> 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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] BCP: Mix-Up Attacks, Implicit Grant Variant

[Warren Parad]

That doesn't make sense to me.

On Wed, Jun 14, 2023, 21:31 Daniel Fett 
wrote:

> Hi Alexander,
> Am 14.06.23 um 15:19 schrieb Alexander Rademann:
>
> *Hello, everyone! Section 4.4.1 of the BCP
> 
> draft lists several variants of mix-up attacks; the description of the
> Implicit grant variant reads as follows: "In the implicit grant, the
> attacker receives an access token instead of the code; the rest of the
> attack works as above." Given the attack description in that section, it is
> not clear to me why an attacker would receive the access token and which
> part the "rest of the attack" refers to. When the Implicit grant is used,
> H-AS sends the access token (via redirect) to the user agent, which
> extracts it and sends it to the client. However, the client does not send
> the access token to A-AS, does it? (I hope that I didn’t overlook anything
> in that section.)*
>
> * I also checked the referenced paper ;
> there, the authors assume that the access token is sent to the
> authorization server under the control of the attacker (or, using their
> terminology, identity provider) to access some resource. [Appendix B, p.
> 31ff] Perhaps this (or some similar) assumption should be added to the
> description of this variant?*
>
> The underlying assumption is that when then user selected to use A-AS in
> the beginning, the access token would also be used with a Resource Server
> under the attacker's control.
>
> -Daniel
>
>
> * I'm sorry if I missed anything or if this has already been addressed
> before, I'm new to this mailing list and did not find anything in the
> archives. Kind regardsAlex*
>
> ___
> 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] BCP: Mix-Up Attacks, Implicit Grant Variant

[Daniel Fett]

Hi Alexander,

Am 14.06.23 um 15:19 schrieb Alexander Rademann:

**

Hello, everyone!

Section 4.4.1 of the BCP 
 
draft lists several variants of mix-up attacks; the description of the 
Implicit grant variant reads as follows: "In the implicit grant, the 
attacker receives an access token instead of the code; the rest of the 
attack works as above."


Given the attack description in that section, it is not clear to me 
why an attacker would receive the access token and which part the 
"rest of the attack" refers to. When the Implicit grant is used, H-AS 
sends the access token (via redirect) to the user agent, which 
extracts it and sends it to the client. However, the client does not 
send the access token to A-AS, does it? (I hope that I didn’t overlook 
anything in that section.)




I also checked the referenced paper 
; there, the authors assume that the 
access token is sent to the authorization server under the control of 
the attacker (or, using their terminology, identity provider) to 
access some resource. [Appendix B, p. 31ff] Perhaps this (or some 
similar) assumption should be added to the description of this variant?


**


The underlying assumption is that when then user selected to use A-AS in 
the beginning, the access token would also be used with a Resource 
Server under the attacker's control.


-Daniel



**

I'm sorry if I missed anything or if this has already been addressed 
before, I'm new to this mailing list and did not find anything in the 
archives.


Kind regards

Alex



___
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] BCP: Mix-Up Attacks, Implicit Grant Variant

[Aaron Parecki]

I've created a pull request to update this section here:
https://github.com/oauthstuff/draft-ietf-oauth-security-topics/pull/82/files

Aaron

On Wed, Jun 14, 2023 at 6:47 AM Aaron Parecki  wrote:

> Hi Alex,
>
> I see what you mean, in Section 4.4.1 with the implicit flow, the sequence
> ends with the redirect back to the client from H-AS with the access token.
> Steps 5 and 6 don't happen with the implicit flow, so "works as above"
> isn't descriptive enough.
>
> The paper describes a slightly different way the attacker gets the access
> token, which is after the client attempts to use the access token from H-AS
> to retrieve resources from A-RS or retrieve user info from A-AS. I believe
> the description of the implicit variant in the Security BCP should be
> updated to make this more clear.
>
> Thanks!
>
> Aaron
>
>
>
> On Wed, Jun 14, 2023 at 6:23 AM Alexander Rademann <
> alexander.radem...@web.de> wrote:
>
>>
>>
>> *Hello, everyone!Section 4.4.1 of the BCP
>> 
>> draft lists several variants of mix-up attacks; the description of the
>> Implicit grant variant reads as follows: "In the implicit grant, the
>> attacker receives an access token instead of the code; the rest of the
>> attack works as above."Given the attack description in that section, it is
>> not clear to me why an attacker would receive the access token and which
>> part the "rest of the attack" refers to. When the Implicit grant is used,
>> H-AS sends the access token (via redirect) to the user agent, which
>> extracts it and sends it to the client. However, the client does not send
>> the access token to A-AS, does it? (I hope that I didn’t overlook anything
>> in that section.)*
>>
>>
>>
>> *I also checked the referenced paper ;
>> there, the authors assume that the access token is sent to the
>> authorization server under the control of the attacker (or, using their
>> terminology, identity provider) to access some resource. [Appendix B, p.
>> 31ff] Perhaps this (or some similar) assumption should be added to the
>> description of this variant?I'm sorry if I missed anything or if this has
>> already been addressed before, I'm new to this mailing list and did not
>> find anything in the archives.Kind regardsAlex*
>> ___
>> 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] BCP: Mix-Up Attacks, Implicit Grant Variant

[Aaron Parecki]

Hi Alex,

I see what you mean, in Section 4.4.1 with the implicit flow, the sequence
ends with the redirect back to the client from H-AS with the access token.
Steps 5 and 6 don't happen with the implicit flow, so "works as above"
isn't descriptive enough.

The paper describes a slightly different way the attacker gets the access
token, which is after the client attempts to use the access token from H-AS
to retrieve resources from A-RS or retrieve user info from A-AS. I believe
the description of the implicit variant in the Security BCP should be
updated to make this more clear.

Thanks!

Aaron



On Wed, Jun 14, 2023 at 6:23 AM Alexander Rademann <
alexander.radem...@web.de> wrote:

>
>
> *Hello, everyone!Section 4.4.1 of the BCP
> 
> draft lists several variants of mix-up attacks; the description of the
> Implicit grant variant reads as follows: "In the implicit grant, the
> attacker receives an access token instead of the code; the rest of the
> attack works as above."Given the attack description in that section, it is
> not clear to me why an attacker would receive the access token and which
> part the "rest of the attack" refers to. When the Implicit grant is used,
> H-AS sends the access token (via redirect) to the user agent, which
> extracts it and sends it to the client. However, the client does not send
> the access token to A-AS, does it? (I hope that I didn’t overlook anything
> in that section.)*
>
>
>
> *I also checked the referenced paper ;
> there, the authors assume that the access token is sent to the
> authorization server under the control of the attacker (or, using their
> terminology, identity provider) to access some resource. [Appendix B, p.
> 31ff] Perhaps this (or some similar) assumption should be added to the
> description of this variant?I'm sorry if I missed anything or if this has
> already been addressed before, I'm new to this mailing list and did not
> find anything in the archives.Kind regardsAlex*
> ___
> 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] BCP: Mix-Up Attacks, Implicit Grant Variant

[Warren Parad]

Presumably, the attacker can get the token by having the Honest-AS redirect
the user to a site controlled by the Attacker. That site then would
redirect the user back to the original site with the Honest-AS token. This
is no different than an ordinary phishing based attack.

On Wed, Jun 14, 2023, 20:24 Alexander Rademann 
wrote:

>
>
> *Hello, everyone!Section 4.4.1 of the BCP
> 
> draft lists several variants of mix-up attacks; the description of the
> Implicit grant variant reads as follows: "In the implicit grant, the
> attacker receives an access token instead of the code; the rest of the
> attack works as above."Given the attack description in that section, it is
> not clear to me why an attacker would receive the access token and which
> part the "rest of the attack" refers to. When the Implicit grant is used,
> H-AS sends the access token (via redirect) to the user agent, which
> extracts it and sends it to the client. However, the client does not send
> the access token to A-AS, does it? (I hope that I didn’t overlook anything
> in that section.)*
>
>
>
> *I also checked the referenced paper ;
> there, the authors assume that the access token is sent to the
> authorization server under the control of the attacker (or, using their
> terminology, identity provider) to access some resource. [Appendix B, p.
> 31ff] Perhaps this (or some similar) assumption should be added to the
> description of this variant?I'm sorry if I missed anything or if this has
> already been addressed before, I'm new to this mailing list and did not
> find anything in the archives.Kind regardsAlex*
> ___
> 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] BCP: Mix-Up Attacks, Implicit Grant Variant

[Alexander Rademann]

*Hello, everyone!Section 4.4.1 of the BCP

draft lists several variants of mix-up attacks; the description of the
Implicit grant variant reads as follows: "In the implicit grant, the
attacker receives an access token instead of the code; the rest of the
attack works as above."Given the attack description in that section, it is
not clear to me why an attacker would receive the access token and which
part the "rest of the attack" refers to. When the Implicit grant is used,
H-AS sends the access token (via redirect) to the user agent, which
extracts it and sends it to the client. However, the client does not send
the access token to A-AS, does it? (I hope that I didn’t overlook anything
in that section.)*



*I also checked the referenced paper ;
there, the authors assume that the access token is sent to the
authorization server under the control of the attacker (or, using their
terminology, identity provider) to access some resource. [Appendix B, p.
31ff] Perhaps this (or some similar) assumption should be added to the
description of this variant?I'm sorry if I missed anything or if this has
already been addressed before, I'm new to this mailing list and did not
find anything in the archives.Kind regardsAlex*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Simplification and consolidation of SD-JWT terminology and format

[Daniel Fett]

Hi Hannes,

maybe it was a bit implicit, but the point of Brian's email was to 
specifically do what you said - discuss this normative change here first.


Although this is an extremely small change, we are conscious about not 
introducing breaking changes unless there is a tangible, practical 
advantage. This is such a change and we would be interested to hear 
feedback from the list.


To illustrate the change further, taking Example 1 from the spec, the 
issuance would be changed from the current format:


eyJhbGciOiAiRVMyNTYifQ.eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZ
Gs2V0JwWnlnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5T
k9PQVljVGo5SE5hQzF3WSIsICJTRE43OU5McEFuSFBta3JkZVlkRWE4OVhaZHNrME04R
EtZU1FPVTJaeFFjIiwgIlh6RnJ6d3NjTTZHbjZDSkRjNnZWSzhCa01uZkc4dk9TS2ZwU
ElaZEFmZEUiLCAiZ2JPc0k0RWRxMngyS3ctdzV3UEV6YWtvYjloVjFjUkQwQVROM29RT
DlKTSIsICJqTUNYVnotLTliOHgzN1ljb0RmWFFpbnp3MXdaY2NjZkZSQkNGR3FkRzJvI
iwgIm9LSTFHZDJmd041V3d2amxGa29oaWRHdmltLTMxT3VsUjNxMGhyRE8wNzgiXSwgI
mlzcyI6ICJodHRwczovL2V4YW1wbGUuY29tL2lzc3VlciIsICJpYXQiOiAxNjgzMDAwM
DAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbGciOiAic2hhLTI1NiIsICJjbmYiO
iB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydiI6ICJQLTI1NiIsICJ4IjogIlRDQUVSM
TladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTGlsRGxzN3ZDZUdlbWMiLCAieSI6ICJaeGppV
1diWk1RR0hWV0tWUTRoYlNJaXJzVmZ1ZWNDRTZ0NGpUOUYySFpRIn19fQ.Kxtki3s03m
PtQQ1huyZvoTggStQWfcNrcKSOZ2Kdn5XNmT-jLK0JGYMPH8_ZF4wiSGhx-KzPNXOwqz
euff9kjA

To this new format:

eyJhbGciOiAiRVMyNTYifQ.eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZ
Gs2V0JwWnlnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5T
k9PQVljVGo5SE5hQzF3WSIsICJTRE43OU5McEFuSFBta3JkZVlkRWE4OVhaZHNrME04R
EtZU1FPVTJaeFFjIiwgIlh6RnJ6d3NjTTZHbjZDSkRjNnZWSzhCa01uZkc4dk9TS2ZwU
ElaZEFmZEUiLCAiZ2JPc0k0RWRxMngyS3ctdzV3UEV6YWtvYjloVjFjUkQwQVROM29RT
DlKTSIsICJqTUNYVnotLTliOHgzN1ljb0RmWFFpbnp3MXdaY2NjZkZSQkNGR3FkRzJvI
iwgIm9LSTFHZDJmd041V3d2amxGa29oaWRHdmltLTMxT3VsUjNxMGhyRE8wNzgiXSwgI
mlzcyI6ICJodHRwczovL2V4YW1wbGUuY29tL2lzc3VlciIsICJpYXQiOiAxNjgzMDAwM
DAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbGciOiAic2hhLTI1NiIsICJjbmYiO
iB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydiI6ICJQLTI1NiIsICJ4IjogIlRDQUVSM
TladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTGlsRGxzN3ZDZUdlbWMiLCAieSI6ICJaeGppV
1diWk1RR0hWV0tWUTRoYlNJaXJzVmZ1ZWNDRTZ0NGpUOUYySFpRIn19fQ.Kxtki3s03m
PtQQ1huyZvoTggStQWfcNrcKSOZ2Kdn5XNmT-jLK0JGYMPH8_ZF4wiSGhx-KzPNXOwqz
euff9kjA~

(Note the additional ~ at the end.)

The suggested clarification in the terminology will help to make the 
spec more concise and clear.


-Daniel

Am 14.06.23 um 09:27 schrieb Hannes Tschofenig:


Hi Brian,


please note that this is a working group item and you cannot make 
decisions in a small group with off-line discussions.


Hence, I suggest to propose the changes to the list and get support 
for it. As you know, we need to follow this approach to give everyone 
in the group a chance to get their voice heard.



Ciao
Hannes


Am 13.06.2023 um 20:58 schrieb Brian Campbell:
Following some offline discussions and feedback there's a plan to 
make some small simplifying changes to the SD-JWT draft to 
consolidate the format and associated terminology. Basically the 
terms "Combined Format for Issuance" and "Combined Format for 
Presentation'' will go away and the whole structure, issued or 
presented, can simply be called an SD-JWT. To align the two formats, 
the last Disclosure will always be followed by a `~` (tilde) 
character (currently the Combined Format for Issuance does not have 
the trailing tilde). When holder/key binding is required for 
presentation of a SD-JWT, a holder/key binding JWT will be appended 
to the end of the whole thing after the trailing tilde. That's all 
there is to it, which isn't much, but I think the result will be 
shortening and simplifying the spec text. And also make the 
terminology easier and more natural when talking about uses or 
applications of SD-JWT.


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


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


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth___
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
> 
>
> 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
> 
> Organizer
> rifaat.s.i...@gmail.com
> Guests
> oauth@ietf.org
> View all guest info
> 
> Reply for oauth@ietf.org
> Yes
> 
> No
> 
> Maybe
> 
> More options
> 
>
> Invitation from Google 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
> 
> ___
> 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] Invitation: IETF OAuth WG Virtual Office Hours @ Wed Jun 14, 2023 12pm - 12:30pm (EDT) (oauth@ietf.org)

[rifaat . s . ietf]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=America/Los_Angeles:20230614T09
DTEND;TZID=America/Los_Angeles:20230614T093000
DTSTAMP:20230614T123639Z
ORGANIZER;CN=rifaat.s.i...@gmail.com:mailto:rifaat.s.i...@gmail.com
UID:5jc0eqt1d1vpkmoh31ekf9q...@google.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:1270833099
CREATED:20230614T123638Z
DESCRIPTION:Rifaat Shekh-Yusef is inviting you to a scheduled Zoom meeting.
 \n\nJoin Zoom Meeting\nhttps://us05web.zoom.us/j/83538035777?pwd=VUJmV2FVV3
 hUN011WjA0UWtiTE1Ddz09\n\nMeeting ID: 835 3803 5777\nPasscode: 0wCaLe\n\n
LAST-MODIFIED:20230614T123638Z
LOCATION:https://us05web.zoom.us/j/83538035777?pwd=VUJmV2FVV3hUN011WjA0UWti
 TE1Ddz09
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:IETF OAuth WG Virtual Office Hours
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] Simplification and consolidation of SD-JWT terminology and format

[Hannes Tschofenig]

Hi Brian,


please note that this is a working group item and you cannot make
decisions in a small group with off-line discussions.

Hence, I suggest to propose the changes to the list and get support for
it. As you know, we need to follow this approach to give everyone in the
group a chance to get their voice heard.


Ciao
Hannes


Am 13.06.2023 um 20:58 schrieb Brian Campbell:

Following some offline discussions and feedback there's a plan to make
some small simplifying changes to the SD-JWT draft to consolidate the
format and associated terminology. Basically the terms "Combined
Format for Issuance" and "Combined Format for Presentation'' will go
away and the whole structure, issued or presented, can simply be
called an SD-JWT. To align the two formats, the last Disclosure will
always be followed by a `~` (tilde) character (currently the Combined
Format for Issuance does not have the trailing tilde). When holder/key
binding is required for presentation of a SD-JWT, a holder/key binding
JWT will be appended to the end of the whole thing after the trailing
tilde. That's all there is to it, which isn't much, but I think the
result will be shortening and simplifying the spec text. And also make
the terminology easier and more natural when talking about uses or
applications of SD-JWT.

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

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