Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

2022-02-18 Thread Mike Jones
See my review comments in the thread “[OAUTH-WG] Comments on 
draft-chadwick-oauth-jwk-uri-00”.

   -- Mike

From: David Chadwick 
Sent: Friday, February 18, 2022 3:52 AM
To: Mike Jones ; Kristina Yasuda 
; oauth@ietf.org
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

Hi Mike

The additional mechanism was published as an I-D last week.


draft-chadwick-oauth-jwk-uri-00.txt

I thought this list had been notified, but my-bad, I see it was not.  So I have 
just sent out the notification now.

So can we get some feedback from this group as well as the OIDC one, before 
progressing either?

Kind regards

David

On 17/02/2022 22:23, Mike Jones wrote:
Hi David,

Rifaat reminded me that yours is the only WGLC comment that has not been 
resolved by publication of -01.  As noted earlier, the substantive differences 
between this draft and the JWK URI draft that you’re proposing are being 
primarily discussed in the OpenID Connect working group, where the JWK 
Thumbprint URI mechanism is used.

In that discussion, you made this issue comment 
https://bitbucket.org/openid/connect/issues/1429/replace-jwk-thumbprint-uri-with-jwk-uri#comment-61838115:

“I agree that adding JWK URI should not exclude JWK Thumbprint URIs. Similarly 
JWK Thumbprint URIs should not exclude JWK URIs.”

That seems to me to indicate that you’re OK with this specification being 
published, while also wanting both working groups to consider your additional 
mechanism when a draft is submitted?  Am I hearing you correctly on that?

At least in my mind, the fact that you might publish another not-equivalent 
mechanism shouldn’t hold up publication of this mechanism.

   Thanks again,
   -- Mike

From: David Chadwick 

Sent: Monday, February 7, 2022 12:54 PM
To: Kristina Yasuda 
; Mike 
Jones ; 
oauth@ietf.org
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

On 07/02/2022 20:42, Kristina Yasuda wrote:
Hi David,

I think your comments below apply to the choices made in another specification 
(SIOP v2 in OIDF), rather than this IETF draft we are discussing.

Hi Kristina

Yes and no.

No, in that the registration of either of the I-Ds as an RFC is a matter for 
this list, and should answer this question, "what is the best way (or ways) of 
creating a URI from a public key."

Yes, in that the SIOPv2 specification requires at least one way of specifying a 
public key as a URI and therefore needs some other standard or standards to 
refer to.
I’ve seen you opened an issue in the OpenID Connect WG Bitbucket. Let’s discuss 
there whether SIOP v2 should use JWK Thumbprint URI.

Yes we can certainly discuss the latter issue in OIDF

Kind regards

David

Best,
Kristina

From: OAuth  On Behalf 
Of David Chadwick
Sent: Sunday, February 6, 2022 2:40 AM
To: Mike Jones 
; 
oauth@ietf.org
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

On 05/02/2022 17:46, Mike Jones wrote:
David, I believe your objections below are actually about the JWK Thumbprint 
[RFC 
7638]
 computation used by this specification, and not the operation defined by this 
specification.  JWK Thumbprint became an RFC in 2015.

Hi Mike

no, my objection is to the JWK Thumbprint URI document. I accept that the JWK 
Thumbprint RFC already exists.

The aim of the SIOPv2 group is to transfer a public key as a URI, so it 
leverages the JWK Thumbprint RFC to do this. As I point out in my I-D, SIOPv2 
transfers the public key and the public key thumbprint. My I-D suggests that we 
simply transfer the public key as a URI then no thumbprint computation is 
necessary by the SIOPv2. The recipient can compute its own thumbprint if it 
needs to by utilising the JWK Thumprint RFC and in this case no hashing 
algorithm needs to be jointly agreed upon.

Kind regards

David

This 
specification

[OAUTH-WG] Comments on draft-chadwick-oauth-jwk-uri-00

2022-02-18 Thread Mike Jones
Thanks for pointing the working group to this individual submission, David.  
Here's some initial comments on the document, as you requested.

First, you specify base64 encoding of the JWK, rather than base64url encoding 
of it.  This would result in non-URL-safe characters in the URI, such as /, +, 
and =.  If you're going to encode things, I suggest using the URL-safe 
base64url encoding.

But secondly, I would not re-encode the JWK fields at all.  I know that David 
Waite had an idea for a representation of JWK URIs where the JSON fields are 
represented as colon-separated pairs in the URI.  So for instance, the example 
JWK at https://datatracker.ietf.org/doc/html/rfc7517#section-3 would be instead 
represented as:

urn:ietf:params:oauth:jwk:kty:EC:crv:P-256:x:f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU:y:x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0:kid:Public%20key%20used%20in%20JWS%20spec%20Appendix%20A.3%20example

This would avoid double base64url-encoding fields, which would prevent 
unnecessary size expansion.

I suggest you work with David if you want to further pursue the idea of a JWK 
URI specification.

   Best wishes,
   -- Mike

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


[OAUTH-WG] Preliminary Meeting Agenda

2022-02-18 Thread Rifaat Shekh-Yusef
As per the *preliminary* meeting agenda, we will be meeting on
*Monday* and *Thursday
*at *14:30-16:30* pm *Vienna* time.
https://datatracker.ietf.org/meeting/113/agenda/

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


Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

2022-02-18 Thread David Chadwick

  
  
Hi Mike


The additional mechanism was published
  as an I-D last week.




  draft-chadwick-oauth-jwk-uri-00.txt



I thought this list had been notified,
  but my-bad, I see it was not.  So I have just sent out the
  notification now.


So can we get some feedback from this
  group as well as the OIDC one, before progressing either?


Kind regards


David


On 17/02/2022 22:23, Mike Jones wrote:


  
  
  
  
Hi David,
 
Rifaat reminded me that yours is the only
  WGLC comment that has not been resolved by publication of
  -01.  As noted earlier, the substantive differences between
  this draft and the JWK URI draft that you’re proposing are
  being primarily discussed in the OpenID Connect working group,
  where the JWK Thumbprint URI mechanism is used.
 
In that discussion, you made this issue
  comment 
https://bitbucket.org/openid/connect/issues/1429/replace-jwk-thumbprint-uri-with-jwk-uri#comment-61838115:
 
“I
agree that adding JWK URI should not exclude JWK Thumbprint
URIs. Similarly JWK Thumbprint URIs should not exclude JWK
URIs.”
 
That seems to me to indicate that you’re OK
  with this specification being published, while also wanting
  both working groups to consider your additional mechanism when
  a draft is submitted?  Am I hearing you correctly on that?
 
At least in my mind, the fact that you
  might publish another not-equivalent mechanism shouldn’t hold
  up publication of this mechanism.
 
  
  Thanks again,
  
  -- Mike
 

  
From: David Chadwick
  
  
  Sent: Monday, February 7, 2022 12:54 PM
  To: Kristina Yasuda
  ; Mike Jones
  ; oauth@ietf.org
  Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI
  document
  

 

  On 07/02/2022 20:42, Kristina Yasuda
wrote:


  Hi David,
   
  I think your comments below apply to the
choices made in another specification (SIOP v2 in OIDF),
rather than this IETF draft we are discussing.

Hi Kristina
Yes and no. 
No, in that the registration of either of the I-Ds as an RFC
  is a matter for this list, and should answer this question,
  "what is the best way (or ways) of creating a URI from a
  public key."
Yes, in that the SIOPv2 specification requires at least one
  way of specifying a public key as a URI and therefore needs
  some other standard or standards to refer to.

  I’ve seen you opened an issue in the
OpenID Connect WG Bitbucket. Let’s discuss there whether
SIOP v2 should use JWK Thumbprint URI.

Yes we can certainly discuss the latter issue in OIDF
Kind regards
David

   
  Best,
  Kristina
   
  

  From: OAuth 
On Behalf Of David Chadwick
Sent: Sunday, February 6, 2022 2:40 AM
To: Mike Jones ;
oauth@ietf.org
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint
URI document

  
   
  
On 05/02/2022 17:46, Mike Jones wrote:
  
  
David, I believe your objections below
  are actually about the JWK Thumbprint [RFC 7638] computation used by
  this specification, and not the operation defined by this
  specification.  JWK Thumbprint became an RFC in 2015.
  
  Hi Mike
  no, my objection is to the JWK Thumbprint URI document. I
accept that the JWK Thumbprint RFC already exists.
  The aim of the SIOPv2 group is to transfer a public key as
a URI, so it leverages the JWK Thumbprint RFC to do this. As
I point out in my I-D, SIOPv2 transfers the public key and
the public key thumbprint. My I-D suggests that we simply
transfer the public key as a URI then no thumbprint
computation is necessary by the SIOPv2. The recipient can
compute its own thumbprint if it needs to by utilising the
JWK Thumprint RFC and in this case no hashing algorithm
needs to be jointly agreed upon.
  Kind regards
  David
  
 
This s

[OAUTH-WG] Fwd: New Version Notification for draft-chadwick-oauth-jwk-uri-00.txt

2022-02-18 Thread David Chadwick

  
  


  A new version of I-D, draft-chadwick-oauth-jwk-uri-00.txt
  has been successfully submitted by David W Chadwick and posted to
  the
  IETF repository.
  
  Name: draft-chadwick-oauth-jwk-uri
  Revision: 00
  Title: JWT URI
  Document date: 2022-02-09
  Group: Individual Submission
  Pages: 6
  URL: https://www.ietf.org/archive/id/draft-chadwick-oauth-jwk-uri-00.txt
  Status: https://datatracker.ietf.org/doc/draft-chadwick-oauth-jwk-uri/
  Htmlized: https://datatracker.ietf.org/doc/html/draft-chadwick-oauth-jwk-uri
  
  
  Abstract:
  This specification registers a kind of URI that represents a JSON
  Web Key (JWK) value. This enables JWKs to be used, for instance,
  as
  key identifiers in contexts requiring URIs.
  
  
  
  
  The IETF Secretariat
  
  

  


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