[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-0001.html>


More information about the Openid-specs-ab mailing list