[Openid-specs-ab] Discovery and Revocation Endpoint (RFC 7009)

John Bradley ve7jtb at ve7jtb.com
Mon Apr 7 14:18:33 UTC 2014


We need to sort out how to extend Discovery.   

If there were a IETF spec then there could be an IANA registry as there will be for the IETF version of registration.

I think that many protocols using OAuth are going to find discovery useful, so eventually the OAuth WG will take it up.

In the interim to prevent interoperability issues we should create a OIDF registry for Discovery extensions like revocation.
It is not mandatory to implement for connect but some IdP will support it.

John B.

On Apr 7, 2014, at 8:10 AM, Thomas Broyer <t.broyer at gmail.com> wrote:

> Sure, but Discovery metadata lists the authorization_endpoint and token_endpoint, so couldn't (shouldn't) it also list the revocation_endpoint (or token_revocation_endpoint) if there's one?
> 
> Or are you saying that it's the role of “the IETF OAuth WG” rather than OpenID Discovery to somehow define the Claim to be used here? (similarly to how OpenID Session Management defines the end_session_endpoint and check_session_iframe claims)
> 
> BTW, Google has a revocation_endpoint claim in their metadata: https://accounts.google.com/.well-known/openid-configuration
> 
> 
> On Mon, Apr 7, 2014 at 3:23 PM, n-sakimura <n-sakimura at nri.co.jp> wrote:
> So, the thinking was that Access Token revocation should be dealt within OAuth.
> 
> ID Token is supposed to be one time / short lived token so revocation was not so much of an issue.
> 
> Session on the other hand has longer lifetime and thus we have end-session.
> 
> Nat
> 
> 
> (2014/04/07 20:30), Thomas Broyer wrote:
> Hi,
> 
> There doesn't seem to be anything in OpenID Discovery related to the
> Revocation Endpoint as defined by RFC 7009.
> 
> It looks to me like a standard sign-out mechanism in a RP would be to:
> 1. revoke all tokens for the user
> 2. invalidate the session (javax.servlet.http.HttpSession#invalidate(),
> PHP's session_destroy, or any similar mechanism; along with any other
> processing needed by the RP)
> 3. redirect to the end_session_endpoint
> 
> Currenly, we can discover the end_session_endpoint, but not the token
> revocation endpoint.
> 
> Is this a known limitation? Is it intentional?
> If not, should I open an issue?
> 
> 
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> 
> 
> 
> -- 
> Nat Sakimura (n-sakimura at nri.co.jp)
> Nomura Research Institute, Ltd.
> Tel:+81-3-6274-1412 Fax:+81-3-6274-1547
> 
> 本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信 することを意図しております。意図された受取人以外の方によるこれらの情報の 開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メール を受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受 信されたメールを削除していただきますようお願い致します。
> PLEASE READ:
> The information contained in this e-mail is confidential and intended for the named recipient(s) only.
> If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system.
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> 
> 
> 
> -- 
> Thomas Broyer
> /tɔ.ma.bʁwa.je/
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

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


More information about the Openid-specs-ab mailing list