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

Brian Campbell bcampbell at pingidentity.com
Fri Jan 24 22:58:06 UTC 2014


In the meantime can we all agree in principle that "revocation_endpoint"
will be the parameter name whenever and wherever it eventually gets defined
and registered? It'll be like a gentlemen's registry, of sorts...


On Fri, Jan 24, 2014 at 3:17 PM, Mike Jones <Michael.Jones at microsoft.com>wrote:

>  [Merging threads]
>
>
>
> I believe that the wiki page that I proposed could act as the registry
> that John proposed for this kind of future work.
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* openid-specs-ab-bounces at lists.openid.net [mailto:
> openid-specs-ab-bounces at lists.openid.net] *On Behalf Of *Mike Jones
> *Sent:* Friday, January 24, 2014 2:12 PM
> *To:* Brian Campbell; Tim Bray
>
> *Cc:* <openid-specs-ab at lists.openid.net>
> *Subject:* Re: [Openid-specs-ab] token revocation endpoint in OP metadata
>
>
>
> I don't think this is a recall-class bug for the current specs.  That
> being said, I think it should be added the next time they are revised or
> could be added as a separate spec.  Does someone want to file an issue
> proposing this for a future revision or new spec so this isn't lost?
>
>
>
> If we're being really diligent, we could also create a wiki page on the
> OpenID wiki with a title something like "Proposed OpenID Connect
> Additions", so people could refer to it before there's an actual spec, and
> reference it from the working group page.  (No, I'm not volunteering to do
> this myself, at present. J)
>
>
>
>                                                                 -- Mike
>
>
>
>
>
>
>
> *From:* openid-specs-ab-bounces at lists.openid.net [mailto:
> openid-specs-ab-bounces at lists.openid.net] *On Behalf Of *John Bradley
> *Sent:* Friday, January 24, 2014 2:14 PM
>
> *To:* Tim Bray
> *Cc:* <openid-specs-ab at lists.openid.net>
> *Subject:* Re: [Openid-specs-ab] token revocation endpoint in OP metadata
>
>
>
> 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/20140124/e5b915ae/attachment.html>


More information about the Openid-specs-ab mailing list