[Openid-specs-ab] Spec Call Notes 16-Aug-18
Mike Jones
Michael.Jones at microsoft.com
Thu Aug 16 16:08:20 UTC 2018
Spec Call Notes 16-Aug-18
Nat Sakimura
Mike Jones
Andreas Solberg
Filip Skokan
Roland Hedberg
Torsten Lodderstedt
JF Lombardo - French Canadian
Henrik Biering
Steffen Klemer - DFN Germany
Rich Levinson
Chris Phillips - Ottawa
Michael Schwartz
OpenID Connect Federation
Andreas shared some of his thoughts about large-scale federations
Andreas suggested using WebFinger for client metadata statements
An RP would be an entity with an identifier, much like an OP
Entities could make statements about other entities
RPs would not be registered in advance
This would entail a number of small changes to the current Federation specification
We could consider each of the changes in turn
The client would have its own keypair
Client Key Pair
Currently, client provides a signed metadata statement
Currently, the validation rules for client registration are not listed in the spec
Andreas talked about preventing multiple clients from using the same metadata statement
Roland is working on a new draft incorporating feedback, including adding validation rules
Roland said that the client needs to self-sign its registration requests
In the Federation draft, the metadata signing key can be different from the client's keys
One for metadata signing, one for normal signing operations
Compatibility and Minimizing Changes
Roland had a goal of touching existing OpenID Connect as little as possible
Rather, he added metadata
Michael Schwartz stated that usability by developers and deployers is the most important design criterion
Roland: In both proposals, there's a trust chain
Andreas: His proposal is compatible with OpenID Connect but doesn't use Client Registration
Roland: I agree but you're adding things that the OP has to understand and implement
Roland: Static registration doesn't scale
Roland: In his draft and normal Connect, the OP can decide what to use, taking the RP's requests into account
Roland: In Andreas' proposal the RP gets to say what the OP does instead
Andreas: Metadata is exchanged in both directions
State
Andreas: His proposal is stateless
OPs don't have to remember client registration information
Andreas: It's currently not specified how long client registrations are valid
This could create complexity in real products
Torsten: There can be errors if credentials or state have expired
What's the same between both proposals
Hierarchical metadata is used by both
Multi-federations
Steffen: There needs to be support for multi-federations
Chris: What happens when an RP is part of multiple federations?
Roland: The Federation draft allows a client to be static or dynamic
The client can participate in multiple federations
Andreas: It's not a problem to also use dynamic client registration, if wanted
Information about the RP
Andreas: A difference is how the OP obtains information about the client
There can be multiple trust roots
For instance, participating in national federations and wider federations
How do you discover what trust root to use in a particular context?
It's up to the client to know what trust roots the OP has
The client's statement is self-signed
It contains references to authorities that can make statements about it
Andreas: Does not allow metadata statements to be wrapped inside others
Always pass by reference, rather than by value
Roland's spec prefers that approach as well
Use Cases
Andreas is also interested in data exchange use cases
He thinks that the same trust model could be used
Even in cases where OpenID Connect is not used
Choices
Roland thinks that both proposals are valuable and should go forward in parallel
Roland: Federation operators want to be in control of things
That's why metadata statements should be sent by reference
For instance, referencing the federation operator metadata
Roland: The RP would decide what federations to register for based on what the OP supports
Steffen: The federation operator, such as EduGain, would publish what federations are supported
Chris: The URL fetch sounds like a top-down command and control setup
How do you validate the referenced metadata statements?
Roland: What you get should be self-contained and signed
You don't have to trust where you got it from
It has a chain of signed metadata statements
Andreas: A difference from SAML federations is that you're not aggregating metadata
Federation operators only make statements about themselves - not about all participants
WebFinger
Roland: In Andreas proposal, the RP is an entity that exists separate from any OP relationships
It has to have a URL where it publishes information about itself
In my proposal, the client doesn't exist until it registers itself
Mike: You could put references to the RP metadata in a JWT client ID
Then you wouldn't need WebFinger
Andreas: Wants RPs to have persistent identifiers
WebFinger is a good protocol match for this use case
Steffen: We concluded that RP URLs don't have to be pre-known since they can be in the JWT at registration time
Mobile Clients
Mike J: How you differentiate between abstract clients and client instances?
For instance, Android applications have many instances of the same client
Steffen: For federations, the client has to run on a Web server that's part of the federation
Mike: Surely, we have to make mobile applications work
Steffen: Mobile applications can't be part of federations
He sent an e-mail to the list about this
Andreas: Additional trust in mobile applications may be limited
Going Forward
Mike: We should continue this valuable discussion
Mike: It would be great if we can eventually have a common write-up laying out the choices
Nat: Our principle of operation is to eventually come to a common standard
It's clear that lots more discussion is needed
Torsten: Do you have a feeling of how long it will take to come up with a list of commonalities and differences?
Roland: It will take more than a week for Andreas and me to put this together
Steffen: Perhaps we can meet in person at an upcoming NORDUnet conference
Roland: Yes. And we should continue discussions in all the other forums, including IIW
Nat: We will continue the Federation discussions on the European time zone call in two weeks
Next Call
The next call is Monday, August 20th at 4pm Pacific Time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180816/504b9fea/attachment.html>
More information about the Openid-specs-ab
mailing list