<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:tahoma,new york,times,serif;font-size:10pt;color:#000000;"><div>Spec call notes 26-Jan-12<br><br>Mike Jones<br>Nat Sakimura<br>John Bradley<br>George Fletcher<br>Edmund Jay<br><br><br><br>Agenda :<br> - Interop<br> - Open Issues<br><br><br>Interop :<br> Need to formalize interop with a spreadsheet with list of participants contact information, endpoints, and features tested.<br> Pam will help setup.<br> Edmund will provide list of currently known implementations to Mike.<br> John made suggestions to UMA group to join interop.<br> Nat may suggest others (NII) to join also.<br><br><br>Issues :<br><br> #521 - Messages 2.1.2.1, etc. - Questioning the ID Token model<br>
Need a FAQ for OpenID Connect to explain rational for the ID Token<br> John blogged about it at <a href="http://www.thread-safe.com/2011/11/openid-connect-tale-of-two-tokens.html">http://www.thread-safe.com/2011/11/openid-connect-tale-of-two-tokens.html</a><br> John will write a shorter version for the FAQ<br><br> #522 - All specs - Questioning the complexity of the Connect design<br> Nat has blogged about this at <a href="http://nat.sakimura.org/2012/01/20/openid-connect-nutshell/">http://nat.sakimura.org/2012/01/20/openid-connect-nutshell/</a><br> The design allows simples things to be simple while also allowing more complex cases.<br>
Complexity and the number of specs are due to layered architectural approach.<br> Other specs can be leveraged by others.<br><br> #523 - Messages 2.1.4 - session_selection_required is leaking PII<br> George has updated the issue with a possible solution. He will post to the list for feedback.<br> The error codes session_selection_required, consent_required, user_mismatched will be deleted and<br>
will be replaced with interaction_required<br>
<br> #524 - Messages 2.5.2 - Aggregated and Distributed Claims should be an extension<br> Issue is invalid because aggregated and distributed claims are part of the core feature and was required by others.<br>
OpenID Connect has already been criticized for having too many specs.<br>
<br> #525 - Standard and Messages- Spec organization unnecessarily complex<br> Marked as invalid because XMPP and other protocol bindings are in progress.<br>
It was proposed in IETF 82 Taipei OAuth meeting that the OAuth spec be separated into an abstract and protocol binding<br>
as part of rechartering discussions.<br><br> #526 - Basic - Basic spec will become the de-facto Connect standard unless deleted<br> Marked as invalid. If Basic becomes the defacto RP standard, then it will facilitate adoption.<br>
<br>
<br> #527 - Registration - Spec is premature<br> Marked as invalid. The spec is required for openness and will promote feedback on what is required.<br>
<br>
<br> #528 - Session - Need for spec not apparent<br> Deferred while spec is being revised.<br>
<br>
<br> #529 - Registration 2.3 Error messages should be Bearer<br> John will fix.<br>
<br> <br>
<br>
</div>
</div></body></html>