[OAUTH-WG] Re: Call for adoption - RFC7523bis

[Dima Postnikov]

I support the adoption of *RFC7523bis* draft.

On Fri, Feb 7, 2025 at 3:38 AM Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is a call for adoption for the *RFC7523bis* draft that was discussed
> recently during the last interim meeting:
> https://datatracker.ietf.org/doc/draft-jones-oauth-rfc7523bis/
>
> Remember that *adoption* does *not* mean a document is *finished*, only
> that it is an *acceptable starting point*.
>
> Please, reply on the mailing list and let us know if you are in favor or
> against adopting this draft as WG document, by Feb 21st.
>
> Regards,
>  Rifaat & Hannes
> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: [RFC7523] JWT-SVID as a client_assertion

[Warren Parad]

It sounds like the SPIRE server is the AS. Which means that it must already
have the clients registered and house their public keys or else the client
signing doesn't work.

Does SPIRE somehow not have this information already?

On Thu, Feb 13, 2025, 01:25 Dmitry Telegin  wrote:

> (Background: exploring the possibility of using SPIFFE as client
> authentication mechanism at the Transaction Token service.)
>
> JWT-SVIDs, defined in SPIFFE, are regular JWTs, though with some
> peculiarities:
> * the "sub", "aud" and "exp" claims are mandatory;
> * the "iss" claim is optional (but would be normally added by SPIRE);
> * the "sub" claim must be set to the workload's SPIFFE ID;
> * the issuer of the JWT-SVID is the SPIRE server and not the workload; the
> workload only controls the acquisition and presentation aspects.
>
> Question 1. Is the use of JWT-SVIDs for client authentication (as a
> client_assertion) compliant with RFC7523(bis)?
>
> Question 2. If so, what would be the best approach to registering such
> clients with the AS (TTS)? Static registration doesn't work very well
> because of the SPIFFE's dynamic nature. DCR could be problematic because
> for JWT-based client auth mechanisms we only have "private_key_jwt" and
> "client_secret_jwt" (and JWT-SVIDs are neither). Should the AS/TTS perform
> some sort of automatic client registration when it first encounters a
> JWT-SVID signed by a trusted issuer?
>
> Thanks,
> Dmitry
> ___
> 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: [RFC7523] JWT-SVID as a client_assertion

[Erin Shepherd]

So I’ve been thinking of similar

> On 13 Feb 2025, at 01:24, Dmitry Telegin  wrote:
> 
> (Background: exploring the possibility of using SPIFFE as client 
> authentication mechanism at the Transaction Token service.)
> 
> JWT-SVIDs, defined in SPIFFE, are regular JWTs, though with some 
> peculiarities:
> * the "sub", "aud" and "exp" claims are mandatory;
> * the "iss" claim is optional (but would be normally added by SPIRE);
> * the "sub" claim must be set to the workload's SPIFFE ID;
> * the issuer of the JWT-SVID is the SPIRE server and not the workload; the 
> workload only controls the acquisition and presentation aspects.
> 
> Question 1. Is the use of JWT-SVIDs for client authentication (as a 
> client_assertion) compliant with RFC7523(bis)?

I don’t see why not. RFC7523 isn’t particularly prescriptive on the exact claim 
set of the JWT.

> Question 2. If so, what would be the best approach to registering such 
> clients with the AS (TTS)? Static registration doesn't work very well because 
> of the SPIFFE's dynamic nature. DCR could be problematic because for 
> JWT-based client auth mechanisms we only have "private_key_jwt" and 
> "client_secret_jwt" (and JWT-SVIDs are neither). Should the AS/TTS perform 
> some sort of automatic client registration when it first encounters a 
> JWT-SVID signed by a trusted issuer?

That’s your big question. I see two options:

1. Accept “spiffe:” as a client ID prefix per 
draft-parecki-oauth-client-id-scheme 
. You’d 
still need to solve the metadata question 
2. Define a “svid_jwt” client auth method and a “spiffe_id” metadata property 
that the client would provide during registration. The client still needs to 
register itself (or be manually registered, or have something register it on 
behalf…)  and know its client ID. 
2a. Do the above and augment dynamic client registration so the client can 
maintain and fetch its own registration with just a SVID JWT (or SVID x.509 
MTLS certificate?)

(I could see something like 2a based upon JWT credentials the client has from 
elsewhere being generically useful, not necessarily tied directly to SPIFFE).

- Erin___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] WIMSE (was Re: Re: [RFC7523] JWT-SVID as a client_assertion)

[John Kemp]

I just wanted to make people on this thread aware of the related IETF 
WIMSE (https://datatracker.ietf.org/group/wimse/about/) work, as well as 
note SPIFFE issue #315 (https://github.com/spiffe/spiffe/issues/315) as 
being pieces of related work to profile JWTs to work with SPIFFE/SPIRE.


Regards, John

El 02/13/25 a las 07:59, Erin Shepherd escribió:

So I’ve been thinking of similar


On 13 Feb 2025, at 01:24, Dmitry Telegin  wrote:

(Background: exploring the possibility of using SPIFFE as client 
authentication mechanism at the Transaction Token service.)


JWT-SVIDs, defined in SPIFFE, are regular JWTs, though with some 
peculiarities:

* the "sub", "aud" and "exp" claims are mandatory;
* the "iss" claim is optional (but would be normally added by SPIRE);
* the "sub" claim must be set to the workload's SPIFFE ID;
* the issuer of the JWT-SVID is the SPIRE server and not the workload; 
the workload only controls the acquisition and presentation aspects.


Question 1. Is the use of JWT-SVIDs for client authentication (as a 
client_assertion) compliant with RFC7523(bis)?


I don’t see why not. RFC7523 isn’t particularly prescriptive on the 
exact claim set of the JWT.


Question 2. If so, what would be the best approach to registering such 
clients with the AS (TTS)? Static registration doesn't work very well 
because of the SPIFFE's dynamic nature. DCR could be problematic 
because for JWT-based client auth mechanisms we only have 
"private_key_jwt" and "client_secret_jwt" (and JWT-SVIDs are neither). 
Should the AS/TTS perform some sort of automatic client registration 
when it first encounters a JWT-SVID signed by a trusted issuer?


That’s your big question. I see two options:

1. Accept “spiffe:” as a client ID prefix per draft-parecki-oauth- 
client-id-scheme . You’d still need to solve the metadata question
2. Define a “svid_jwt” client auth method and a “spiffe_id” metadata 
property that the client would provide during registration. The client 
still needs to register itself (or be manually registered, or have 
something register it on behalf…)  and know its client ID.
2a. Do the above and augment dynamic client registration so the client 
can maintain and fetch its own registration with just a SVID JWT (or 
SVID x.509 MTLS certificate?)


(I could see something like 2a based upon JWT credentials the client has 
from elsewhere being generically useful, not necessarily tied directly 
to SPIFFE).


- Erin

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org


--
Independent Security Architect
t: +1.413.645.4169
e: stable.pseudo...@gmail.com

https://www.linkedin.com/in/johnk-am9obmsk/
https://github.com/frumioj

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Call for adoption - RFC7523bis

[Dave Tonge]

Hi

I support adoption

Thanks

Dave

On Thu, 6 Feb 2025 at 17:37, Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is a call for adoption for the *RFC7523bis* draft that was discussed
> recently during the last interim meeting:
> https://datatracker.ietf.org/doc/draft-jones-oauth-rfc7523bis/
>
> Remember that *adoption* does *not* mean a document is *finished*, only
> that it is an *acceptable starting point*.
>
> Please, reply on the mailing list and let us know if you are in favor or
> against adopting this draft as WG document, by Feb 21st.
>
> Regards,
>  Rifaat & Hannes
> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>

-- 


Moneyhub Enterprise is a trading style of Moneyhub Financial Technology 
Limited which is authorised and regulated by the Financial Conduct 
Authority ("FCA"). Moneyhub Financial Technology is entered on the 
Financial Services Register (FRN 809360) at https://register.fca.org.uk/ 
. Moneyhub Financial Technology is registered 
in England & Wales, company registration number 06909772. Registered 
address: C/O Roxburgh Milkins Limited Merchants House North, Wapping Road, 
Bristol, United Kingdom, BS1 4RW, United Kingdom. Moneyhub Financial 
Technology Limited 2024 © Moneyhub Enterprise.


DISCLAIMER: This email 
(including any attachments) is subject to copyright, and the information in 
it is confidential. Use of this email or of any information in it other 
than by the addressee is unauthorised and unlawful. Whilst reasonable 
efforts are made to ensure that any attachments are virus-free, it is the 
recipient's sole responsibility to scan all attachments for viruses. All 
calls and emails to and from this company may be monitored and recorded for 
legitimate purposes relating to this company's business. Any opinions 
expressed in this email (or in any attachments) are those of the author and 
do not necessarily represent the opinions of Moneyhub Financial Technology 
Limited or of any other group company.
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Call for adoption - RFC7523bis

[Nat Sakimura]

+1

On Thu, Feb 13, 2025 at 10:33 PM Dave Tonge 
wrote:

> Hi
>
> I support adoption
>
> Thanks
>
> Dave
>
> On Thu, 6 Feb 2025 at 17:37, Rifaat Shekh-Yusef 
> wrote:
>
>> All,
>>
>> This is a call for adoption for the *RFC7523bis* draft that was
>> discussed recently during the last interim meeting:
>> https://datatracker.ietf.org/doc/draft-jones-oauth-rfc7523bis/
>>
>> Remember that *adoption* does *not* mean a document is *finished*, only
>> that it is an *acceptable starting point*.
>>
>> Please, reply on the mailing list and let us know if you are in favor or
>> against adopting this draft as WG document, by Feb 21st.
>>
>> Regards,
>>  Rifaat & Hannes
>> ___
>> OAuth mailing list -- oauth@ietf.org
>> To unsubscribe send an email to oauth-le...@ietf.org
>>
>
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
> Limited which is authorised and regulated by the Financial Conduct
> Authority ("FCA"). Moneyhub Financial Technology is entered on the
> Financial Services Register (FRN 809360) at https://register.fca.org.uk/.
> Moneyhub Financial Technology is registered in England & Wales, company
> registration number 06909772. Registered address: C/O Roxburgh Milkins
> Limited Merchants House North, Wapping Road, Bristol, United Kingdom, BS1
> 4RW, United Kingdom. Moneyhub Financial Technology Limited 2024 © Moneyhub
> Enterprise.
>
> DISCLAIMER: This email (including any attachments) is subject to
> copyright, and the information in it is confidential. Use of this email or
> of any information in it other than by the addressee is unauthorised and
> unlawful. Whilst reasonable efforts are made to ensure that any attachments
> are virus-free, it is the recipient's sole responsibility to scan all
> attachments for viruses. All calls and emails to and from this company may
> be monitored and recorded for legitimate purposes relating to this
> company's business. Any opinions expressed in this email (or in any
> attachments) are those of the author and do not necessarily represent the
> opinions of Moneyhub Financial Technology Limited or of any other group
> company.
>
> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Call for adoption - RFC7523bis

[Michael Fraser]

Hi,

I support adoption

Thanks,

Michael Fraser

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: [External Sender] Re: Call for adoption - RFC7523bis

[George Fletcher]

I support adoption

On Thu, Feb 13, 2025 at 9:28 AM Nat Sakimura  wrote:

> +1
>
> On Thu, Feb 13, 2025 at 10:33 PM Dave Tonge 
> wrote:
>
>> Hi
>>
>> I support adoption
>>
>> Thanks
>>
>> Dave
>>
>> On Thu, 6 Feb 2025 at 17:37, Rifaat Shekh-Yusef 
>> wrote:
>>
>>> All,
>>>
>>> This is a call for adoption for the *RFC7523bis* draft that was
>>> discussed recently during the last interim meeting:
>>> https://datatracker.ietf.org/doc/draft-jones-oauth-rfc7523bis/
>>> 
>>>
>>> Remember that *adoption* does *not* mean a document is *finished*, only
>>> that it is an *acceptable starting point*.
>>>
>>> Please, reply on the mailing list and let us know if you are in favor or
>>> against adopting this draft as WG document, by Feb 21st.
>>>
>>> Regards,
>>>  Rifaat & Hannes
>>> ___
>>> OAuth mailing list -- oauth@ietf.org
>>> To unsubscribe send an email to oauth-le...@ietf.org
>>>
>>
>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
>> Limited which is authorised and regulated by the Financial Conduct
>> Authority ("FCA"). Moneyhub Financial Technology is entered on the
>> Financial Services Register (FRN 809360) at https://register.fca.org.uk/
>> .
>> Moneyhub Financial Technology is registered in England & Wales, company
>> registration number 06909772. Registered address: C/O Roxburgh Milkins
>> Limited Merchants House North, Wapping Road, Bristol, United Kingdom, BS1
>> 4RW, United Kingdom. Moneyhub Financial Technology Limited 2024 © Moneyhub
>> Enterprise.
>>
>> DISCLAIMER: This email (including any attachments) is subject to
>> copyright, and the information in it is confidential. Use of this email or
>> of any information in it other than by the addressee is unauthorised and
>> unlawful. Whilst reasonable efforts are made to ensure that any attachments
>> are virus-free, it is the recipient's sole responsibility to scan all
>> attachments for viruses. All calls and emails to and from this company may
>> be monitored and recorded for legitimate purposes relating to this
>> company's business. Any opinions expressed in this email (or in any
>> attachments) are those of the author and do not necessarily represent the
>> opinions of Moneyhub Financial Technology Limited or of any other group
>> company.
>>
>> ___
>> OAuth mailing list -- oauth@ietf.org
>> To unsubscribe send an email to oauth-le...@ietf.org
>>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> 
> @_nat_en
> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>

__



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
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: late review of draft-ietf-oauth-selective-disclosure-jwt-15

[Rohan Mahy]

Hi,
I have a few comments on Section 10.1.

However, when the user only discloses a birthdate to one Verifier and a
> postal code to another Verifier, the two Verifiers should not be able to
> determine that they were interacting with the same user.

Regarding presentation unlinkability and verifier/verifier unlinkability,
isn't it sufficient to compare the signature on two SD-JWTs to have a very
high probability that they are the same credential? Likewise, if there is a
confirmation key present in the SD-JWT, isn't generating a JWK thumbprint
from the confirmation key and comparing it, sufficient to identify a holder
who uses the same key (even potentially across credentials)?
Maybe this is meant to be qualified by the later comments about batch
issuance, or maybe this is a leftover sentence?

I would mention that the presence of an audience claim in the SD-CWT could
reveal information about the verifier(s), while an audience claim in the
KBT can be customized per-verifier

I like the paragraph discussing power dynamics between verifiers and
issuers.

Where such callbacks are necessary, they MUST be executed in a manner that
> preserves privacy and does not disclose details about the credential to the
> Issuer.

I think this is an RFC 6919 MUST (BUT WE KNOW YOU WON'T). Seriously, you
are saying an honest verifier MUST do something, instead of defining a
privacy-preserving Verifier as one that takes certain measures to protect
holder privacy.

Even if the Verifier is both honest and is willing to protect the holder's
privacy, the Issuer might construct revocation checks that are resistant to
privacy protection. It still might be worth suggesting some mechanisms (ex:
Oblivious HTTP, VPNs, Tor) for those revocation check URLs that don't leak
information about the holder to the issuer.

Likewise, claims carrying time information, like iat, exp, and nbf, MUST
> either be randomized within a time period considered appropriate (e.g.,
> randomize iat within the last 24 hours and calculate exp accordingly) or
> rounded (e.g., rounded down to the beginning of the day).

I would add that the timezone may or may not be sensitive. If it is,
consider rounding `iat`s to midnight UTC.

Thanks!
-rohan


On Mon, Feb 10, 2025 at 5:52 PM Rohan Mahy  wrote:

> Hi,
> Today I did a full read and review of
> draft-ietf-oauth-selective-disclosure-jwt-15. Below are my comments.
> Thanks,
> -rohan
>
> Overall
>
>- I found the Introduction, and Sections 2 and 3, not concrete enough
>to follow what is being discussed in a first read through. I proposed a new
>Section 1.3 which I think has the right spirit.
>- I am super happy that we are not using did: URIs in the document.
>- I  think it is very useful to have a capitalized name for the
>digests. I suggest Blinded Hash. Another good choice is Redacted Claim 
> Hash.
>- All the SHOULD statements should explain why they are not MUSTs or
>under what circumstances the implementer could do something different that
>still makes sense.
>- If a validity claim (ex: exp, nbf) is redacted, does it need to be
>validated if the relevant disclosure is provided?
>
>
> Abstract
> suggestion: s/for the selective disclosure of individual elements of a
> JSON-encoded data structure used as the payload of a JSON Web Signature
> (JWS)/for the selective disclosure of individual elements of a JSON-encoded
> JSON Web Signature (JWS) payload/
> Intro:
> suggestion: s/A new model is emerging that/Another model/
> Section 1.1
> suggestions:
> s/SD-JWT is a composite structure enabling selective disclosure of its
> contents/SD-JWT is a composite structure, consisting of a JWS plus optional
> disclosures, enabling selective disclosure of portions of the JWS payload.
> s/SD-JWT+KB is a composite structure enabling cryptographic key binding
> when presented to the Verifier./SD-JWT+KB is a composite structure of an
> SD-JWT and a cryptographic key binding that can be presented to and
> verified by the Verifier./
> Section 1.2
> Selective Disclosure: "JWT Claims Set" is used in a definition but not yet
> defined. Since the definition in RFC7519 is somewhat circular, maybe s/JWT
> Claims Set/JWS payload/
> Selectively Disclosable JWT: s/Issuer-signed JWT (JWS,
> [RFC7515])/Issuer-signed JWS [RFC7515] (often a JWT)/
> Disclosure: s/The Disclosure is used to calculate a digest for the
> respective claim.//
> *add:* Blinded Hash: The cryptographic digest (hash) of a specific
> Disclosure
> Key Binding JWT (KB-JWT): s/A Key Binding JWT is said to "be tied to" a
> particular SD-JWT when its payload is signed using the key included in the
> SD-JWT payload, and also contains a hash of the SD-JWT in its sd_hash
> claim. A JWT for proving Key Binding as defined in Section 4.3
> ./A
> Key Binding JWT is said to "be tied to" a particular SD-JWT when the KB-JWT
> is signed using the key included