[WG-OTTO] Summary of OTTO / refeds collaboration call
mike at gluu.org
Thu Nov 10 16:10:51 CST 2016
Leif and others provided some valuable feedback for which the OTTO WG is
Here are some of my take-aways. A link to more complete notes:
(For those on the call, send comments|pull request to amend anything I
got wrong or missed.)
1. I think we're on the same page about the trust model: downloading the
federation's signed metadata or querying for a specific entity's
metadata works. The OIDC federation spec presents a new trust model that
moves some of the signing work to the federation participant. OTTO can
support this (it's actually easy for the federation operator to support,
because all it's doing is publishing its public key), but whether this
is a good idea or not will be determined later, and is out of scope of
2. OTTO publishes a lot of CRUD API's. The goal behind this was to
provide guidance to implementers to encourage the development of open
source tools like Jagger and Federation Registry. However, if you are
not an implementer of a federation operator platform, you don't have to
care about these extra API's, and that's fine!
3. There is some overlap between OTTO and MDQ with regard to obtaining a
subset of federation metadata. Leif's contention is that MDQ is
sufficient. The OTTO WG's position is that MDQ was considered, and that
it was not deemed to provide a flexible enough way to express filters or
to specify what type of objects to return. The key assumption of OTTO is
that Linked Data (in our case expressed as JSON-LD), which was used to
optimize search results for web search engines, can be used to enable
fast and effective searching of federation metadata as well. It also
provides a large base schema (http://schema.org) and a convenient and
expressive extension mechanism. Net-net, OTTO should take a closer look
at MDQ, and make sure we're not missing something.
4. Leif expressed an interesting point that what's really needed is a
more efficient way for trust "oracles" to update each other about
changes, ideally asynchronously. The trust oracle can be the local
federation, however as trust becomes more mature, perhaps we'll see a
proliferation of trust oracles to the edge of the network. How all these
trust oracles will keep in sync is a challenge. Perhaps this is a use
case for the newly formed IETF OAuth2 Security Events WG?
5. David Walker also pointed out that the number of trusted sources
(i.e. federation or other organizations that convey meaningful trust
information) is increasing. So whatever the solution, it needs to
support the specification of several "upstream" trust oracles.
I'm probably missing some key takeaways... but I think that covers the
jist of it.
- Mike Schwartz
PS: BTW, we need a better term then "trust oracle"!
PPS: Join the OTTO WG:
More information about the WG-OTTO