[Openid-specs-ab] Spec Call note 03-Oct-2013

Mike Jones Michael.Jones at microsoft.com
Thu Oct 3 20:50:19 UTC 2013


For what it's worth, I'm strongly against making breaking changes to the specs at this point - including changing https://self-issued.me/ to a different name.  As for the stability of .me - it's my impression that .me is a cash cow for Montenegro just like .tv is for Tuvalu, and is therefore highly unlikely to ever go away.  The registration is already owned by the OpenID Foundation.  Let's keep using it.

As for questions #879 and #880, I'd like to hear from implementers whether they think having these endpoints would result in code simplifications or whether they really wouldn't.  Nat, can you talk to the people in Japan who've built self-issued OPs about their thoughts?

                                                                Thanks,
                                                                -- Mike

From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Edmund Jay
Sent: Thursday, October 03, 2013 11:58 AM
To: openid-specs-ab
Subject: [Openid-specs-ab] Spec Call note 03-Oct-2013

Spec Call notes 03-Oct-2013

Attendees
  Nat Sakimura
  Justin Richer
  Edmund Jay


Agenda
  Spec Refactoring
  Issues
  Session Management


Spec Refactoring
  Mike was absent from call so it was not discussed.


Issues
  #882: All - JWT and JOSE specification versions
  #881: Discovery 1 - Relationship to OAuth Dynamic Registration
      The above 2 issues are editorial changes

  #879: Messages 6.1 - The OpenID Foundation may consider hosting a site https://self-issued.me/
  #880: Messages 6.2 - The OpenID Foundation may consider hosting the endpoint https://self-issued.me/registration/1.0/
      Nat and Justin suggests using https://self-issued.openid.net/ rather than a domain in another country.

  #878: Messages 2.1.1.1 Define "negative response" for id_token_hint
      Summary from coversations in the mailing list :
         When prompt=none is requested and the user is not logged in, the error response will be login_required
         When prompt=none is requested and there is no id_token_hint, Breno suggests trying to satisfy the request
         if there is a signed-in user who has approved the application previously

  #876: Google "iss" value missing https://
      Needs further discussion

  #877: Messages 2.1.3 Description of interaction_required, login_required, session_selection_required and consent_required conflicts with prompt none specification
      It is agreed that language will be changed to MUST NOT to keep consistency



Session Management
      Needs more interop work
      Edmund has session management RP working with Microsoft OP
      Currently seeking Google's session management endpoints (please respond if anyone knows)
      The Session Management spec is not as mature as the other specs and also subject to cookie and local storage policies.
      Will need to explore the possibility of going forward without Session Management
      Edmund will suggest text to clarify some points for current doc.



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


More information about the Openid-specs-ab mailing list