[Openid-specs-ab] token revocation endpoint in OP metadata

Nat Sakimura sakimura at gmail.com
Sat Jan 25 01:15:47 UTC 2014


A registry and an entry associated with a documentation would be good. 

For that matter, registry for the parameter names for indicating end points would be useful. 

We need to establish a light weight governance mechanism to avoid duplicative entries though if we were to establish it on our own. 

Another idea would be to leverage 6.2. Link Relation Type Registry [1] maintained by IANA. Perhaps that is a preferred way. 

[1] http://tools.ietf.org/search/rfc5988#section-6.2

=nat via iPhone

Jan 24, 2014 23:14、John Bradley <ve7jtb at ve7jtb.com> のメッセージ:

> Connect dosen't mention the token revocation extension at all.
> 
> There needs to be a registry for this sort of extension.   We had hoped that that would be part of the IETF dynamic registration spec, but that has stalled in the WG thanks to parties unnamed.
> 
> I don't think adding it to the openID dynamic reg spec would be worth triggering another review cycle.
> 
> We could possibly do a short standalone document on Configuring Token revocation for Connect here we could document the Discovery and registration parameters.
> We probably should have added it as a optional parameter after revocation became a RFC but that is water under the bridge.
> 
> I think it should be documented separately as a RFC or Connect document.
> 
> John B.
> 
>> On Jan 24, 2014, at 6:57 PM, Tim Bray <tbray at textuality.com> wrote:
>> 
>> Feels like a bug.
>> 
>> 
>>> On Fri, Jan 24, 2014 at 1:41 PM, Brian Campbell <bcampbell at pingidentity.com> wrote:
>>> A colleague asked me yesterday if the token revocation endpoint (from RFC7009 [1]) was one of the OpenID Provider Metadata parameters[2]. Which it is not. But should we consider adding it? 
>>> 
>>> [1] http://tools.ietf.org/html/rfc7009
>>> [2] http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata
>>> 
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> 
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> 
> _______________________________________________
> 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/20140125/0a73a9fe/attachment-0001.html>


More information about the Openid-specs-ab mailing list