debbucci at gmail.com
Wed Jul 1 12:37:05 UTC 2015
Understood and same page.
Assume the registry could also be use to possibly display a subset of
entries in a UI ..like... PHRs known/approved/registered with a
particular provider portal (pcp)
On Jul 1, 2015 8:24 AM, "Josh Mandel" <Joshua.Mandel at childrens.harvard.edu>
> Hi Debbie,
> Just to make sure we're on the same page here: OAuth 2.0 Dynamic Client
Registration doesn't, in general, require a "registry" to function. It's
designed to work well in an environment where clients talk directly to an
authorization server and register themselves.
> That said, registries can be a useful addition to the ecosystem as a way
to provide some "certified" or "registered" or "pre-approved" or "trusted"
claims about a given client. In the Blue Button REST API, we did produce a
(very minimal) registry; details are at:
> On Wed, Jul 1, 2015 at 8:06 AM, Debbie Bucci <debbucci at gmail.com> wrote:
>> For my own understanding/research/testing would someone please point me
to an operational [dynamic client discovery] registry in use today I did
not see a link to one on the BB+ API site - but that is where I'd like to
start - I looked at the two obvious places but could only see options to
download bundles. The spec looks complete - lots of thought went into
it. I'd hope its in use somewhere. If there are other projects using
one - that may be helpful as well -- at least to compare the schema. I
know that SAML registries are used to express all sorts of relevant
technical and policy information and there was even a desire to have a
common registry across protocols. If this is moving towards
standardization would be a good thing to know as well.
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-heart