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

[Andreas Åkre Solberg]

Thanks for taking the time to comment.

First question, how did you get twitter handle @erlang ?

I registered it a long time ago. At the university I studied queuing theory, and it was a tribute to https://en.wikipedia.org/wiki/Agner_Krarup_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?

Exactly.

But one question I have is public clients, for example a javascript application running in the browser can't host a Webfinger endpoint.

You are right, the browser cannot host a webfinger endpoint, nor does it have to.

Native apps and SPAs have in common that they run on the device of the end user. Typically all users of an application will share the same client_id and metadata, and the app does not hold its own credentials, but instead rely on some sort of control of the redirect_uri value, either through the domain where the SPA is hosted or through a custom scheme such as mycoolapp:// registered through apple or google.

There is no restrictions on where the SPA entity statement of a client is hosted. The requirement instead is that the entity statement can be resolved from the client_id through the use of webfinger. The entity that services the entity statement will be reflected in the client_id, but there is no required relationship between the client_id and the redirect_uri. If the app has an application provider that hosts the SPA app, the application provider can host the webfinger server and serve the entity statment of the shared statement of all instances of that app. Alternatively the federation may offer to host entity statements for the client.

Such an entity statement would typically be like this:

{
    "iss": "https://feide.no/federation",
    "sub": "https://feide.no/application/394747",
    "metadata": {
        "openidClient": {
            "redirect_uris": [
                "coolapp://"
            ]
        }
    },
    "jwks": null
}


I think that trends and new requirements would make it interesting to discuss the ability for SPAs and native apps to establish their own credentials (self generated key pairs). This will result in separate client_ids for each deployent, while the redirect_uris would be shared. How we build the federated infrastructure have consequences for how easy it would be to build and how smooth this will run.

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?

No.

* Dynamic client registration derives from the platform centric paradigm, and has no obvious role in the distributed / federation approach.
* We would like to be kind with the clients, loading the responsibility of fetching all the needed entity statements from the federation and pushing them to the provider is unncessary and adds complexity to the client.
* Obviously we need to target the concern of delays during the authentication flow. There need to be caching involved.

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).

In the current draft, the entity statement contains a jwks claim that is protocol independent.
When a federation states something about a service provider, the jwks claim represent the public key the service provides uses to sign statements about itself
When the service provider offers its self issued statement using webfinger, it signs a statement that can be validated with that pubic key. However the statement that the service provider makes about it self can also include a new public key that can be used in OpenID message exchange signing requests. If the service provider to do that will use the protocol agnostic jwks claim or it should add a jwks in the openid client metadata or if it should be allowed to use jwks_uri for yet another indirection can be a discussion on its own. In general I think we need to be careful and not add too many options of how to do things (or too many layers of indirection). This is where SAML failed.

When it comes to key rotation, JWT Federation should be able to support that perfectly. A client or provider can easily generate new keys and update their own self-issued statement.

Currently OpenID Core [10.1.1] promotes rotation of keys using jwks_uri. AFAIK jwks_uri drops back to rely on TLS only, and should be completely avoided in the federation use cases. In fact I even think that providers that would like to do key rotatation will benefit from JWT federation even if it does not need the federation part.

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.

There are some properties that a federation would like to enforce all leaf nodes (clients or providers) derived from it. These properties can be like restrictions on LoA or attributes that can be trusted. These properties would go into the metadata claim that is merged with the complete trust chain (similar to the currenct openid connect federation draft).

JWT Federation also allows for any entity to issue statements about themselves. In a normal authentication flow, a provider would not usually fetch Feides statement about it self, but instead fetch Feides statement about a univerity or service provider. Information in Feides statement about itself would therefor not impact the technical trust between the two entities.

I think it would be useful to define a separate entity type of ‘federation’ with a metadata schema allowing legal and technical contacts, urls to policy documents, documentation. This could also be the most appropriate place to add links to provider discovery services (APIs for list of universities, like we use in educational federations). The infr

The content of this self issued federation statement can be trustred using the same validation chain.


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

I’d say that it is out of scope.

Today most federations manage client registration by providing Developer/Admin Dashboard where administrator end-users authenticates and copy and paste SAML metadata into a form.

I foresee a first generation of OpenID Connect Developer dashboards, where the user enters the client_id into a form. The dashboard then fetches the self issued entity statements using WebFinger, and asks the user to verify that the public key matches. Next the admin adds the entityid of the federation into the client config, and the client should be ready to work with providers in the federation.

I also expect there to be a next generation where the developer dashboards are replaced with APIs, expecting Oauth tokens with an authenticated administrator. This allows client registration to be tightly integrated with CI for both production and test builds, and better follows the application lifecycles.


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

Is there a separate document describing the inter-federation use case? Please send me the link.

Trust is established in a tree structure, and a trust chain is one path trough that tree. Inter-federation is just another item on the chain. Nothing special about it.

The challenge is specifying metadata semantics that allow a federation to express the exact delegated trust how it is intended. A federation that delegates trust with no restrictions would be more or less an empty metadata object as part of the chain/tree.


Andreas Åkre Solberg
Senior Technical Architect
UNINETT – https://uninett.no
https://www.linkedin.com/in/andreassolberg/


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180806/823778aa/attachment.html>