[Openid-specs-ab] Comments on Solberg JWT Federation

Leif Johansson leifj at mnt.se
Thu Aug 2 20:47:13 UTC 2018

On 2018-08-02 22:10, Mike Schwartz via Openid-specs-ab wrote:
> Andreas,

I'm not Andreas but I'll jump in anyway...

> First question, how did you get twitter handle @erlang ?
> Here are some comments, just prima facie:
> 1. I like the idea to leverage Webfinger. One of my core concerns about
> he current OIDC federation draft is that it's too static in a day and
> age when we're all using lots of API's. And WebFinger is already used by
> OP's that support dynamic configuration, so why not use it? But one
> question I have is public clients, for example a javascript application
> running in the browser can't host a Webfinger endpoint.

There are technologies available that could help to establish
service endpoints from browsers, eg webrtc data channels...

> 2. Wouldn't it be better for the client to present it's metadata during
> dynamic client registration, rather then requiring the OP to call back
> to the RP's Webfinger URL at authentication time?

Maybe support both. If I look at the majority of services in my $dayjob
context almost none of them are public clients - most are classical web
apps or singlepage apps with jwt token authn for API calls. For all of
these this proposal would be much simpler than SAML but could (with some
minor modifications) share several of the good properties of SAML.

In fact I know of several "simple-jwt-to-SAML" gateways that have been
deployed to support exactly this usecase.

> 3. Are you also proposing the use of OP,RP metadata for signing_keys,
> signing_keys_uri, and signed_jwks_uri ? Another federation challenge is
> that key rotation for the jwks_uri happens frequently if you are
> following guidelines for best practices (every two days).

My only concern here is that we enable name-to-key binding that doesn't
rely on the webpki. I don't share the (recently popular) belief among
the browser cool-kids that because we now have CT the webpki is suddenly

My trust, my keys.

> 4. What about metadata for the federation itself? Perhaps the federation
> wants to publish certain guidelines, like what are the SAML attributes
> it recommends its participants to support? For example, InCommon
> recommends use of eduPerson.

I actually think this should be out of scope or at the very least pushed
to a later time. Syntax and semantics for describing policy and trust
parameters are a notoriuous hard problem.

> 5. How would a client register with the federation to get that
> persistent identifier? Or is that out of scope of your proposal?

Out of scope would be my recommentation.

> 6. Did you go through the inter-federation use case? Is the data
> duplicated? Or does one federation refer back to the other federation?

Duplication would be my recommendation. There is no such thing as
transitive trust - there is only derived trust (also all trust is
local and trust does not scale :-))

7. We should really try to step away from COFU - Configure On First
Use - in favor of aggregated pre-configured trust. Andreas proposal
has the benefit of allowing this. The provider can learn (out of band)
about clients it needs to talk to and can discover their metadata
before the first authn request arrives.

When OpenIDC is used with a small number (or only one) provider
this is seldom a problem but in mesh federations the majority of
clients will have to go through a lot of time-consuming config
on every authn. Instead the provider should aggregate & cache
to avoid delays.

	Cheers Leif

> - Mike
> ------------------------
> Michael Schwartz
> Gluu
> Founder / CEO
> mike at gluu.org
> https://www.linkedin.com/in/nynymike/
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

More information about the Openid-specs-ab mailing list