<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">Spec Call Notes 16-Aug-18<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Nat Sakimura<o:p></o:p></p>
<p class="MsoNormal">Mike Jones<o:p></o:p></p>
<p class="MsoNormal">Andreas Solberg<o:p></o:p></p>
<p class="MsoNormal">Filip Skokan<o:p></o:p></p>
<p class="MsoNormal">Roland Hedberg<o:p></o:p></p>
<p class="MsoNormal">Torsten Lodderstedt<o:p></o:p></p>
<p class="MsoNormal">JF Lombardo - French Canadian<o:p></o:p></p>
<p class="MsoNormal">Henrik Biering<o:p></o:p></p>
<p class="MsoNormal">Steffen Klemer - DFN Germany<o:p></o:p></p>
<p class="MsoNormal">Rich Levinson<o:p></o:p></p>
<p class="MsoNormal">Chris Phillips - Ottawa<o:p></o:p></p>
<p class="MsoNormal">Michael Schwartz<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">OpenID Connect Federation<o:p></o:p></p>
<p class="MsoNormal"> Andreas shared some of his thoughts about large-scale federations<o:p></o:p></p>
<p class="MsoNormal"> Andreas suggested using WebFinger for client metadata statements<o:p></o:p></p>
<p class="MsoNormal"> An RP would be an entity with an identifier, much like an OP<o:p></o:p></p>
<p class="MsoNormal"> Entities could make statements about other entities<o:p></o:p></p>
<p class="MsoNormal"> RPs would not be registered in advance<o:p></o:p></p>
<p class="MsoNormal"> This would entail a number of small changes to the current Federation specification<o:p></o:p></p>
<p class="MsoNormal"> We could consider each of the changes in turn<o:p></o:p></p>
<p class="MsoNormal"> The client would have its own keypair<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Client Key Pair<o:p></o:p></p>
<p class="MsoNormal"> Currently, client provides a signed metadata statement<o:p></o:p></p>
<p class="MsoNormal"> Currently, the validation rules for client registration are not listed in the spec<o:p></o:p></p>
<p class="MsoNormal"> Andreas talked about preventing multiple clients from using the same metadata statement<o:p></o:p></p>
<p class="MsoNormal"> Roland is working on a new draft incorporating feedback, including adding validation rules<o:p></o:p></p>
<p class="MsoNormal"> Roland said that the client needs to self-sign its registration requests<o:p></o:p></p>
<p class="MsoNormal"> In the Federation draft, the metadata signing key can be different from the client's keys<o:p></o:p></p>
<p class="MsoNormal"> One for metadata signing, one for normal signing operations<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Compatibility and Minimizing Changes<o:p></o:p></p>
<p class="MsoNormal"> Roland had a goal of touching existing OpenID Connect as little as possible<o:p></o:p></p>
<p class="MsoNormal"> Rather, he added metadata<o:p></o:p></p>
<p class="MsoNormal"> Michael Schwartz stated that usability by developers and deployers is the most important design criterion<o:p></o:p></p>
<p class="MsoNormal"> Roland: In both proposals, there's a trust chain<o:p></o:p></p>
<p class="MsoNormal"> Andreas: His proposal is compatible with OpenID Connect but doesn't use Client Registration<o:p></o:p></p>
<p class="MsoNormal"> Roland: I agree but you're adding things that the OP has to understand and implement<o:p></o:p></p>
<p class="MsoNormal"> Roland: Static registration doesn't scale<o:p></o:p></p>
<p class="MsoNormal"> Roland: In his draft and normal Connect, the OP can decide what to use, taking the RP's requests into account<o:p></o:p></p>
<p class="MsoNormal"> Roland: In Andreas' proposal the RP gets to say what the OP does instead<o:p></o:p></p>
<p class="MsoNormal"> Andreas: Metadata is exchanged in both directions<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">State<o:p></o:p></p>
<p class="MsoNormal"> Andreas: His proposal is stateless<o:p></o:p></p>
<p class="MsoNormal"> OPs don't have to remember client registration information<o:p></o:p></p>
<p class="MsoNormal"> Andreas: It's currently not specified how long client registrations are valid<o:p></o:p></p>
<p class="MsoNormal"> This could create complexity in real products<o:p></o:p></p>
<p class="MsoNormal"> Torsten: There can be errors if credentials or state have expired<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">What's the same between both proposals<o:p></o:p></p>
<p class="MsoNormal"> Hierarchical metadata is used by both<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Multi-federations<o:p></o:p></p>
<p class="MsoNormal"> Steffen: There needs to be support for multi-federations<o:p></o:p></p>
<p class="MsoNormal"> Chris: What happens when an RP is part of multiple federations?<o:p></o:p></p>
<p class="MsoNormal"> Roland: The Federation draft allows a client to be static or dynamic<o:p></o:p></p>
<p class="MsoNormal"> The client can participate in multiple federations<o:p></o:p></p>
<p class="MsoNormal"> Andreas: It's not a problem to also use dynamic client registration, if wanted<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Information about the RP<o:p></o:p></p>
<p class="MsoNormal"> Andreas: A difference is how the OP obtains information about the client<o:p></o:p></p>
<p class="MsoNormal"> There can be multiple trust roots<o:p></o:p></p>
<p class="MsoNormal"> For instance, participating in national federations and wider federations<o:p></o:p></p>
<p class="MsoNormal"> How do you discover what trust root to use in a particular context?<o:p></o:p></p>
<p class="MsoNormal"> It's up to the client to know what trust roots the OP has<o:p></o:p></p>
<p class="MsoNormal"> The client's statement is self-signed<o:p></o:p></p>
<p class="MsoNormal"> It contains references to authorities that can make statements about it<o:p></o:p></p>
<p class="MsoNormal"> Andreas: Does not allow metadata statements to be wrapped inside others<o:p></o:p></p>
<p class="MsoNormal"> Always pass by reference, rather than by value<o:p></o:p></p>
<p class="MsoNormal"> Roland's spec prefers that approach as well<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Use Cases<o:p></o:p></p>
<p class="MsoNormal"> Andreas is also interested in data exchange use cases<o:p></o:p></p>
<p class="MsoNormal"> He thinks that the same trust model could be used<o:p></o:p></p>
<p class="MsoNormal"> Even in cases where OpenID Connect is not used<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Choices<o:p></o:p></p>
<p class="MsoNormal"> Roland thinks that both proposals are valuable and should go forward in parallel<o:p></o:p></p>
<p class="MsoNormal"> Roland: Federation operators want to be in control of things<o:p></o:p></p>
<p class="MsoNormal"> That's why metadata statements should be sent by reference<o:p></o:p></p>
<p class="MsoNormal"> For instance, referencing the federation operator metadata<o:p></o:p></p>
<p class="MsoNormal"> Roland: The RP would decide what federations to register for based on what the OP supports<o:p></o:p></p>
<p class="MsoNormal"> Steffen: The federation operator, such as EduGain, would publish what federations are supported<o:p></o:p></p>
<p class="MsoNormal"> Chris: The URL fetch sounds like a top-down command and control setup<o:p></o:p></p>
<p class="MsoNormal"> How do you validate the referenced metadata statements?<o:p></o:p></p>
<p class="MsoNormal"> Roland: What you get should be self-contained and signed<o:p></o:p></p>
<p class="MsoNormal"> You don't have to trust where you got it from<o:p></o:p></p>
<p class="MsoNormal"> It has a chain of signed metadata statements<o:p></o:p></p>
<p class="MsoNormal"> Andreas: A difference from SAML federations is that you're not aggregating metadata<o:p></o:p></p>
<p class="MsoNormal"> Federation operators only make statements about themselves - not about all participants<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">WebFinger<o:p></o:p></p>
<p class="MsoNormal"> Roland: In Andreas proposal, the RP is an entity that exists separate from any OP relationships<o:p></o:p></p>
<p class="MsoNormal"> It has to have a URL where it publishes information about itself<o:p></o:p></p>
<p class="MsoNormal"> In my proposal, the client doesn't exist until it registers itself<o:p></o:p></p>
<p class="MsoNormal"> Mike: You could put references to the RP metadata in a JWT client ID<o:p></o:p></p>
<p class="MsoNormal"> Then you wouldn't need WebFinger<o:p></o:p></p>
<p class="MsoNormal"> Andreas: Wants RPs to have persistent identifiers<o:p></o:p></p>
<p class="MsoNormal"> WebFinger is a good protocol match for this use case<o:p></o:p></p>
<p class="MsoNormal"> Steffen: We concluded that RP URLs don't have to be pre-known since they can be in the JWT at registration time<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Mobile Clients<o:p></o:p></p>
<p class="MsoNormal"> Mike J: How you differentiate between abstract clients and client instances?<o:p></o:p></p>
<p class="MsoNormal"> For instance, Android applications have many instances of the same client<o:p></o:p></p>
<p class="MsoNormal"> Steffen: For federations, the client has to run on a Web server that's part of the federation<o:p></o:p></p>
<p class="MsoNormal"> Mike: Surely, we have to make mobile applications work<o:p></o:p></p>
<p class="MsoNormal"> Steffen: Mobile applications can't be part of federations<o:p></o:p></p>
<p class="MsoNormal"> He sent an e-mail to the list about this<o:p></o:p></p>
<p class="MsoNormal"> Andreas: Additional trust in mobile applications may be limited<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Going Forward<o:p></o:p></p>
<p class="MsoNormal"> Mike: We should continue this valuable discussion<o:p></o:p></p>
<p class="MsoNormal"> Mike: It would be great if we can eventually have a common write-up laying out the choices<o:p></o:p></p>
<p class="MsoNormal"> Nat: Our principle of operation is to eventually come to a common standard<o:p></o:p></p>
<p class="MsoNormal"> It's clear that lots more discussion is needed<o:p></o:p></p>
<p class="MsoNormal"> Torsten: Do you have a feeling of how long it will take to come up with a list of commonalities and differences?<o:p></o:p></p>
<p class="MsoNormal"> Roland: It will take more than a week for Andreas and me to put this together<o:p></o:p></p>
<p class="MsoNormal"> Steffen: Perhaps we can meet in person at an upcoming NORDUnet conference<o:p></o:p></p>
<p class="MsoNormal"> Roland: Yes. And we should continue discussions in all the other forums, including IIW<o:p></o:p></p>
<p class="MsoNormal"> Nat: We will continue the Federation discussions on the European time zone call in two weeks<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Next Call<o:p></o:p></p>
<p class="MsoNormal"> The next call is Monday, August 20th at 4pm Pacific Time<o:p></o:p></p>
</div>
</body>
</html>