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

Nat Sakimura sakimura at gmail.com
Thu Nov 8 18:28:16 UTC 2012

Sounds like you are replying to a different thread...

We are not talking about adding metadata to the discovery document. We are
talking about how to express the metadata (discovery document). It is not
adding new information.

=nat via iPhone

Nov 8, 2012 13:21、Mike Jones <Michael.Jones at microsoft.com> wrote:

  From a developer perspective, including unnecessary information is nearly
always bad.

Your code still has to understand the meaning of the fields it uses.
Adding metadata doesn’t change that.

                                                            -- Mike

*From:* Nat Sakimura [mailto:sakimura at gmail.com <sakimura at gmail.com>]
*Sent:* Thursday, November 08, 2012 10:16 AM
*To:* Richer, Justin P.
*Cc:* Mike Jones; openid-specs-ab at lists.openid.net Group
*Subject:* Re: [Openid-specs-ab] OIDC Discovery and OAuth2 LRDD

>From a developer perspective, a uniform interface is always good,  because
I can reuse my codes, probably just use libraries so I do not have write
much code, etc.


On Fri, Nov 9, 2012 at 2:58 AM, Richer, Justin P. <jricher at mitre.org> wrote:

The wouldn't a better approach be to take the constructs of LRDD and move
them into the JSON world? Maybe using the HAL linking format that Nat's
brought up.

What bothers me is a bespoke solution for a generic problem in OIDC.

 -- Justin

On Nov 8, 2012, at 12:37 PM, Mike Jones wrote:

  Part of what makes JSON more popular and successful than XML is that
there *isn't* any usually-unnecessary metadata or introspection facilities
built into the format.  In my opinion, trying to superimpose this structure
on our use of JSON after the fact is both unnecessary and counter to what
developers want.

They're voting with their feet and we want their votes.

-- Mike

*From: *Nat Sakimura
*Sent: *11/8/2012 10:12 AM
*To: *Richer, Justin P.
*Cc: *openid-specs-ab at lists.openid.net Group
*Subject: *Re: [Openid-specs-ab] OIDC Discovery and OAuth2 LRDD

P.S. You can see how I was feeling from my blog post


It predates http://datatracker.ietf.org/doc/draft-wmills-oauth-lrdd/


On Thu, Nov 8, 2012 at 10:58 PM, Nat Sakimura <sakimura at gmail.com> wrote:

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

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.



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

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


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

Nat Sakimura (=nat)

Chairman, OpenID Foundation

Nat Sakimura (=nat)

Chairman, OpenID Foundation

Nat Sakimura (=nat)

Chairman, OpenID Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20121108/dde0c613/attachment.html>

More information about the Openid-specs-ab mailing list