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

Brian Campbell bcampbell at pingidentity.com
Mon Apr 7 14:13:48 UTC 2014


This came up, more or less, a couple of months ago. See
http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20140120/004581.htmlfor
some of the discussion.
On Apr 7, 2014 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/ <http://xn--nna.ma.xn--bwa-xxb.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/a421a53a/attachment-0001.html>


More information about the Openid-specs-ab mailing list