[Openid-specs-ab] OIDC Discovery and OAuth2 LRDD

Nat Sakimura sakimura at gmail.com
Thu Nov 8 13:58:43 UTC 2012


It is a bit late in the game, but I do agree being able to express them in
the link based structure (not LRDD though, it needs to be JSON) is nice.

HAL or Hyper-meta schema would be good.

Note: none of them are RFC however, so we need to do something in that
respect.

The only reason that it is a flat thing is that there were a strong desire
to do very simple thing at the beginning. Maybe OAuth discovery document is
simple enough that a flat schema makes sense, but OIDC configuration is
complex enough that we may want to consider an alternate format.

Having said that, there is a political issues as well. It is soooo late in
the documents life cycle and as we do not want to give the community
impression that we are still unstable, whether it is worth pursuing should
be evaluated carefully.

Best,

Nat

On Thu, Nov 8, 2012 at 12:43 AM, Richer, Justin P. <jricher at mitre.org>wrote:

> One of my longstanding complaints about OIDC Discovery is that while it
> tries to follow a generalizable process to find the issuer, the document
> that defines the server configuration is a completely bespoke JSON
> structure. I hadn't seen this document before, but there was recently an
> admittedly-incomplete attempt by William Mills to put together a spec to
> define LRDD based discovery for OAuth2 endpoints and configuration
> parameters.
>
> http://datatracker.ietf.org/doc/draft-wmills-oauth-lrdd/
>
> Shouldn't we be using some kind of host link-based configuration format
> like this instead of a new JSON document? Shouldn't we be trying to engage
> the larger service discovery community as opposed to just pasting something
> in for OIDC alone?
>
>  -- Justin
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20121108/bbacfde1/attachment.html>


More information about the Openid-specs-ab mailing list