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

Brian Campbell bcampbell at pingidentity.com
Mon Apr 7 14:55:58 UTC 2014


No problem, checking the archives is nice in theory but not always in
practice. It took me a while to find that thread and I knew it was there!
On Apr 7, 2014 8:28 AM, "Thomas Broyer" <t.broyer at gmail.com> wrote:

> Thanks!
> I'll reference that message if/when I'm asked about that name choice and
> where it's defined.
>
> (obviously I hadn't checked the archives *shame on me*)
>
>
> On Mon, Apr 7, 2014 at 4:13 PM, Brian Campbell <bcampbell at pingidentity.com
> > wrote:
>
>> 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
>>>
>>>
>
>
> --
> Thomas Broyer
> /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140407/fe0edbb6/attachment.html>


More information about the Openid-specs-ab mailing list