Metadata on client registration

56 views
Skip to first unread message

Roland Hedberg

unread,
Jun 18, 2020, 3:49:38 AM6/18/20
to openid-feder...@googlegroups.com
Hi!

Right now an RP can signal which client registration method it can use by setting ‘federation_type’
in its metadata.

I think I want to change the parameter name to ‘client_registation_type’ because that’s what it’s all about.

On the OP’s side it can publish it’s client registration support using ‘federation_type_supported’ which then 
also should change name, to ‘client_registation_type_supported’.
The OP has to publish another thing and that is what auth methods it supports.
Here I’d like to use the parameter name ‘client_registration_auth_methods_supported’.
This parameter then should publish 2 sets of auth methods, one for ’normal’ authorization request is used and one for 
when pushed authorization request is used.

If we use the normal abbreviation of pushed authorization request, PAR and consequently use AR for ’normal’ authorization request,
then I would propose we use an JSON object as value. Like this:

‘client_registation_type_supported': {‘AR’: [‘request_object’], ‘PAR’:[‘private_key_jwt’, ‘ self_signed_tls_client_auth’]}

Anyone against ?

- Roland

Otium cum dignitate - latin proverb

Vladimir Dzhuvinov

unread,
Jun 18, 2020, 4:32:24 AM6/18/20
to openid-feder...@googlegroups.com

Hi Roland,

On 18/06/2020 10:49, Roland Hedberg wrote:
Hi!

Right now an RP can signal which client registration method it can use by setting ‘federation_type’
in its metadata.

I think I want to change the parameter name to ‘client_registation_type’ because that’s what it’s all about.

This name change makes a lot of sense.



On the OP’s side it can publish it’s client registration support using ‘federation_type_supported’ which then 
also should change name, to ‘client_registation_type_supported’.

How about `client_registration_types_supported` ? Since it's a JSON array, with potentially multiple values?


The OP has to publish another thing and that is what auth methods it supports.
Here I’d like to use the parameter name ‘client_registration_auth_methods_supported’.
This parameter then should publish 2 sets of auth methods, one for ’normal’ authorization request is used and one for 
when pushed authorization request is used.

If we use the normal abbreviation of pushed authorization request, PAR and consequently use AR for ’normal’ authorization request,
then I would propose we use an JSON object as value. Like this:

‘client_registation_type_supported': {‘AR’: [‘request_object’], ‘PAR’:[‘private_key_jwt’, ‘ self_signed_tls_client_auth’]}

Shouldn't that be client_registration_auth_methods_supported?

This nested format has not occurred before, but it has the benefit that it keeps everything under one roof and can potentially accommodate with other endpoints as well (who knows ;)


Anyone against ?

I welcome these changes.

Vladimir



- Roland

Otium cum dignitate - latin proverb

--
You received this message because you are subscribed to the Google Groups "openid-federation-interop" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openid-federation-...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openid-federation-interop/8638390B-4592-491B-AC85-6DAD631304E8%40catalogix.se.
-- 
Vladimir Dzhuvinov

Roland Hedberg

unread,
Jun 18, 2020, 4:37:52 AM6/18/20
to Vladimir Dzhuvinov, openid-feder...@googlegroups.com

On 18 Jun 2020, at 10:32, Vladimir Dzhuvinov <vlad...@connect2id.com> wrote:

Hi Roland,

On 18/06/2020 10:49, Roland Hedberg wrote:
Hi!

Right now an RP can signal which client registration method it can use by setting ‘federation_type’
in its metadata.

I think I want to change the parameter name to ‘client_registation_type’ because that’s what it’s all about.

This name change makes a lot of sense.

Excellent !


On the OP’s side it can publish it’s client registration support using ‘federation_type_supported’ which then 
also should change name, to ‘client_registation_type_supported’.

How about `client_registration_types_supported` ? Since it's a JSON array, with potentially multiple values?

Yes, of course.

The OP has to publish another thing and that is what auth methods it supports.
Here I’d like to use the parameter name ‘client_registration_auth_methods_supported’.
This parameter then should publish 2 sets of auth methods, one for ’normal’ authorization request is used and one for 
when pushed authorization request is used.

If we use the normal abbreviation of pushed authorization request, PAR and consequently use AR for ’normal’ authorization request,
then I would propose we use an JSON object as value. Like this:

‘client_registation_type_supported': {‘AR’: [‘request_object’], ‘PAR’:[‘private_key_jwt’, ‘ self_signed_tls_client_auth’]}

Shouldn't that be client_registration_auth_methods_supported?

Yes, a typical example of thinking one think and writing another.

This nested format has not occurred before, but it has the benefit that it keeps everything under one roof and can potentially accommodate with other endpoints as well (who knows ;)

Who know :-)

Anyone against ?

I welcome these changes.

Great !

— Roland
Can anything be sadder than work left unfinished? Yes, work never begun. -Christina Rossetti, poet (5 Dec 1830-1894) 

Mike Jones

unread,
Jun 19, 2020, 12:37:52 PM6/19/20
to Roland Hedberg, Vladimir Dzhuvinov, openid-feder...@googlegroups.com

We typically use lowercase for parameter names, so I’d advocate “par” rather than “PAR”.

 

                                                                     -- Mike

--

You received this message because you are subscribed to the Google Groups "openid-federation-interop" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openid-federation-...@googlegroups.com.

Vladimir Dzhuvinov

unread,
Jun 19, 2020, 12:50:10 PM6/19/20
to Roland Hedberg, 'Mike Jones' via openid-federation-interop

I +1 Mike's suggestion.


Vladimir



---- 'Mike Jones' via openid-federation-interop wrote ----

Roland Hedberg

unread,
Jun 20, 2020, 2:28:51 AM6/20/20
to Vladimir Dzhuvinov, 'Mike Jones' via openid-federation-interop
OK


— Roland

It is curious that physical courage should be so common in the world, and moral courage so rare. -Mark Twain, author and humorist (30 Nov 1835-1910)

Vladimir Dzhuvinov

unread,
Jun 29, 2020, 2:12:32 PM6/29/20
to Roland Hedberg, 'Mike Jones' via openid-federation-interop

Could client_registation_type also be made plural - client_registation_types, since it's a JSON array?

A new version of the SDK (8.11) was released today which supports the new OP parameters:
  • client_registration_types_supported
  • client_registration_auth_methods_supported
The old parameter names will continue to work, to ensure backward compatibility.

The client metadata will be touched in the next release.

Vladimir

Mike Jones

unread,
Jun 29, 2020, 2:26:01 PM6/29/20
to Vladimir Dzhuvinov, Roland Hedberg, 'Mike Jones' via openid-federation-interop

I agree that since it’s plural, its name should have the “s” in it.

Roland Hedberg

unread,
Jun 30, 2020, 9:42:47 AM6/30/20
to Vladimir Dzhuvinov, 'Mike Jones' via openid-federation-interop
Just pushed a new version to the GitHub repo.


This issue was fixed there.

Vladimir Dzhuvinov

unread,
Jun 30, 2020, 11:16:23 AM6/30/20
to openid-feder...@googlegroups.com

Thanks!

Mike Jones

unread,
Jun 30, 2020, 1:19:12 PM6/30/20
to Roland Hedberg, Vladimir Dzhuvinov, 'Mike Jones' via openid-federation-interop

I just pulled from master and diffed.  Here’s additional issues I’d like to see addressed before we publish draft 12.

 

  • client_registration_type should be client_registration_types, since it’s a list.
  • I’d prefer that client_registration_auth_methods_supported be client_registration_authn_methods_supported so it’s clear that client authentication is occurring.
  • s/The OP MUST publish that is supports/The OP MUST publish that it supports/
  • You changed “two” to “three” in “When it comes to client authentication the applicable authentication methods are three:” but the list that follows only has two entries.  What’s behind this inconsistency?
  • s/There are three different path/There are three different paths/
  • s/about them self/about themselves/

 

                                                       Thanks,

Roland Hedberg

unread,
Jun 30, 2020, 1:31:40 PM6/30/20
to Mike Jones, 'Mike Jones' via openid-federation-interop

On 30 Jun 2020, at 19:19, 'Mike Jones' via openid-federation-interop <openid-feder...@googlegroups.com> wrote:

I just pulled from master and diffed.  Here’s additional issues I’d like to see addressed before we publish draft 12.
 
  • client_registration_type should be client_registration_types, since it’s a list.
  • I’d prefer that client_registration_auth_methods_supported be client_registration_authn_methods_supported so it’s clear that client authentication is occurring.
  • s/The OP MUST publish that is supports/The OP MUST publish that it supports/
  • You changed “two” to “three” in “When it comes to client authentication the applicable authentication methods are three:” but the list that follows only has two entries.  What’s behind this inconsistency?

There are 2 mTLS variants, one with self-signed certificates and the other one with Certificates signed by a CA.
I regard them as separate methods.

  • s/There are three different path/There are three different paths/
  • s/about them self/about themselves/

I’ve applied the rest of the diffs.

— Roland

The higher up you go, the more mistakes you are allowed. Right at the top, if you make enough of them, it's considered to be your style. 
-Fred Astaire, dancer, actor, singer, musician, and choreographer (10 May 1899-1987)

Mike Jones

unread,
Jun 30, 2020, 1:47:20 PM6/30/20
to Roland Hedberg, 'Mike Jones' via openid-federation-interop

You wrote “There are 2 mTLS variants, one with self-signed certificates and the other one with Certificates signed by a CA.

I regard them as separate methods.”  I understand what you’re saying and agree with it.

 

My main point is an editorial one.  The spec says “three” followed by a list of two, which will confuse readers.  Please break out the two mTLS variants so that they are separate list items.  Then “three” will be followed by a list of three items.

 

                                                       Thanks,

                                                       -- Mike

 

P.S.  When you next push, please build and also push the .txt and .html versions.

 

From: Roland Hedberg <rol...@catalogix.se>
Sent: Tuesday, June 30, 2020 10:32 AM
To: Mike Jones <Michae...@microsoft.com>
Cc: 'Mike Jones' via openid-federation-interop <openid-feder...@googlegroups.com>
Subject: Re: Metadata on client registration

 

 

Roland Hedberg

unread,
Jun 30, 2020, 2:56:48 PM6/30/20
to Mike Jones, 'Mike Jones' via openid-federation-interop
Done

On 30 Jun 2020, at 19:47, 'Mike Jones' via openid-federation-interop <openid-feder...@googlegroups.com> wrote:

You wrote “There are 2 mTLS variants, one with self-signed certificates and the other one with Certificatessigned by a CA.

“The first principal is that you must not fool yourself — and you are the easiest person to fool” 
— Richard Feynman

Mike Jones

unread,
Jun 30, 2020, 4:00:23 PM6/30/20
to Roland Hedberg, 'Mike Jones' via openid-federation-interop

This looks good now.  Let me know when you’re ready for -12 to be published.

 

                                                       -- Mike

Vladimir Dzhuvinov

unread,
Jun 30, 2020, 5:09:52 PM6/30/20
to openid-feder...@googlegroups.com

Hi Roland,


I noticed some examples still use the old params:

2 x federation_types_supported


In 9.1.1.1. Using Request Object there is a "sub" specified for the request object JWT.

If the intent was to set it to prevent some potential JWT misuse if the "sub" is left undefined, then I'd suggest to have it set to the entity ID of the relying party, rather than the entity ID of the OP, since the JWT is "about" authentication of the RP.

https://github.com/rohe/oidcfederation/blob/master/draft/openid-connect-federation-1_0.txt#L2324

The example that follows does set "sub" to the RP entity ID:

"sub": "https://rp.example.com"


Vladimir

--
You received this message because you are subscribed to the Google Groups "openid-federation-interop" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openid-federation-...@googlegroups.com.

Mike Jones

unread,
Jun 30, 2020, 8:14:56 PM6/30/20
to Roland Hedberg, 'Mike Jones' via openid-federation-interop

Oops – I just caught on omission.  Please create a History entry for draft -12.

 

                                                       Thanks,

                                                       -- Mike

Roland Hedberg

unread,
Jul 1, 2020, 3:32:26 AM7/1/20
to Mike Jones, 'Mike Jones' via openid-federation-interop
Fixed.
Also fixed Vlad’s catch.

And finally I changed the example of automatic registration in the appendix to use a request object instead
of client assertion.

Ready for publication.

-- 
You received this message because you are subscribed to the Google Groups "openid-federation-interop" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openid-federation-...@googlegroups.com.

— Roland

There is nothing you cannot prove if your outlook is only sufficiently limited. (Dorothy L. Sayers, ”Whose body?”)




Vladimir Dzhuvinov

unread,
Jul 1, 2020, 6:16:52 AM7/1/20
to openid-feder...@googlegroups.com

Caught one more issue in the auto example:

https://github.com/rohe/oidcfederation/blob/master/draft/openid-connect-federation-1_0.txt#L2379

Request object (OIDC style) requires client_id, response_type and scope as top-level parameters.

https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests

So that the request is a valid OAuth 2.0 Authorization Request, values for the response_type and client_id parameters MUST be included using the OAuth 2.0 request syntax, since they are REQUIRED by OAuth 2.0. The values for these parameters MUST match those in the Request Object, if present.
Even if a scope parameter is present in the referenced Request Object, a scope parameter MUST always be passed using the OAuth 2.0 request syntax containing the openid scope value to indicate to the underlying OAuth 2.0 logic that this is an OpenID Connect request.

This will also make the request JAR (draft 21) compliant (requires only client_id as other top-level parameter).

Vladimir

Roland Hedberg

unread,
Jul 1, 2020, 11:08:11 AM7/1/20
to Vladimir Dzhuvinov, openid-feder...@googlegroups.com
Fixed

Mike Jones

unread,
Jul 1, 2020, 12:33:38 PM7/1/20
to Roland Hedberg, Vladimir Dzhuvinov, openid-feder...@googlegroups.com

Looks good.  Should I publish this as draft 12 now?

 

                                                       -- Mike

 

From: openid-feder...@googlegroups.com <openid-feder...@googlegroups.com> On Behalf Of Roland Hedberg
Sent: Wednesday, July 1, 2020 8:08 AM
To: Vladimir Dzhuvinov <vlad...@connect2id.com>

Roland Hedberg

unread,
Jul 1, 2020, 12:49:45 PM7/1/20
to Mike Jones, Vladimir Dzhuvinov, openid-feder...@googlegroups.com
Go ahead !

On 1 Jul 2020, at 18:33, 'Mike Jones' via openid-federation-interop <openid-feder...@googlegroups.com> wrote:

Looks good.  Should I publish this as draft 12 now?
 
                                                       -- Mike
 
From: openid-feder...@googlegroups.com <openid-feder...@googlegroups.com> On Behalf Of Roland Hedberg
Sent: Wednesday, July 1, 2020 8:08 AM
To: Vladimir Dzhuvinov <vlad...@connect2id.com>
Cc: openid-feder...@googlegroups.com
Subject: Re: Metadata on client registration
 
Fixed
On 1 Jul 2020, at 12:16, Vladimir Dzhuvinov <vlad...@connect2id.com> wrote:
 
Caught one more issue in the auto example:
Request object (OIDC style) requires client_id, response_type and scope as top-level parameters.
 
So that the request is a valid OAuth 2.0 Authorization Request, values for theresponse_type and client_id parameters MUST be included using the OAuth 2.0 request syntax, since they are REQUIRED by OAuth 2.0. The values for these parameters MUST match those in the Request Object, if present. 
Even if a scope parameter is present in the referenced Request Object, a scopeparameter MUST always be passed using the OAuth 2.0 request syntax containing theopenid scope value to indicate to the underlying OAuth 2.0 logic that this is an OpenID Connect request.

Mike Jones

unread,
Jul 1, 2020, 1:31:23 PM7/1/20
to Roland Hedberg, Vladimir Dzhuvinov, openid-feder...@googlegroups.com

This is now published at https://openid.net/specs/openid-connect-federation-1_0-12.html and https://openid.net/specs/openid-connect-federation-1_0.html.

 

I’ll also make a blog post on openid.net saying that this release has been informed by the experiences from the June 2020 interop.

 

                                                       Thanks all!

                                                       -- Mike

Vladimir Dzhuvinov

unread,
Jul 1, 2020, 4:26:11 PM7/1/20
to openid-feder...@googlegroups.com

Thanks Mike and congratulations everyone!

Switching the client auth on auto registration to JAR or JAR was a significant update and I believe will make the spec appeal to other application domains.


We updated the SDK to draft 12 earlier today, plus the RP examples:

https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/examples/openid-connect/federation#auth-request-with-auto-client-registration


Regarding D - open issues - "How are federation operator keys retrieved?" - I think we should aim for federations which can be operated in a fully automated fashion and avoid manual configs where possible. This means automatic key retrieval, updates and roll-over. Since the anchor JWK set is available in its statement at a well known URL, all participating entities can be configured with the anchor URL and then let to work out the rest automatically - meaning retrieve and cache the anchor keys. Thus relying on PKI / TLS for the key authenticity and integrity.

If a statement issued by the anchor about another entity refers to a JWK "kid" that isn't cached, this can be used as a signal to trigger a refresh of the JWK set. For this to work efficiently the statement "jwks" will need to add a requirement for including an identifier for each JWK (currently not required).

If the anchor keys will be configured manually by some, using some other way to distribute them, it will help to provide some general guidance / pointers how to do this securely.


Vladimir

Roland Hedberg

unread,
Jul 2, 2020, 2:46:40 AM7/2/20
to Vladimir Dzhuvinov, openid-feder...@googlegroups.com

On 1 Jul 2020, at 22:26, Vladimir Dzhuvinov <vlad...@connect2id.com> wrote:

Thanks Mike and congratulations everyone!

Switching the client auth on auto registration to JAR or JAR was a significant update and I believe will make the spec appeal to other application domains.


We updated the SDK to draft 12 earlier today, plus the RP examples:

https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/examples/openid-connect/federation#auth-request-with-auto-client-registration

Cool!

Regarding D - open issues - "How are federation operator keys retrieved?" - I think we should aim for federations which can be operated in a fully automated fashion and avoid manual configs where possible.

Yes, yes and yes !!

This means automatic key retrieval, updates and roll-over.

For sure.

Since the anchor JWK set is available in its statement at a well known URL, all participating entities can be configured with the anchor URL and then let to work out the rest automatically - meaning retrieve and cache the anchor keys. Thus relying on PKI / TLS for the key authenticity and integrity.

That’s the crux. So far we have aimed to not be relying on PKI/TLS.
If we where to follow your proposal I’m still not comfortable with getting an entity statement and not being able to verify it’s 
correctness/authenticity independent of how I got it.

If a statement issued by the anchor about another entity refers to a JWK "kid" that isn't cached, this can be used as a signal to trigger a refresh of the JWK set. For this to work efficiently the statement "jwks" will need to add a requirement for including an identifier for each JWK (currently not required).

That is a good idea.

If the anchor keys will be configured manually by some, using some other way to distribute them, it will help to provide some general guidance / pointers how to do this securely. 

This is one of the hardest problems. I’ve played around with a number of different ’solutions’ but so far have not found
the ultimate one.

For federations build on existing trust relationships, like for higher eduction and research, government organisations,
trade organisations and the like there is a central authority that can be used.

For ad hoc federations not so much.

So maybe we should just list a set of possible ways depending on the environment.

— Roland
Scratch a pessimist and you find often a defender of privilege. -William Beveridge, economist and reformer (5 Mar 1879-1963) 

Reply all
Reply to author
Forward
0 new messages