[WG-OTTO] Summary of OTTO / refeds collaboration call

Mike Schwartz mike at gluu.org
Thu Nov 10 16:10:51 CST 2016


Refeds gurus,

Leif and others provided some valuable feedback for which the OTTO WG is 
very grateful.

Here are some of my take-aways. A link to more complete notes:
https://github.com/KantaraInitiative/wg-otto/blob/master/minutes/060-otto_minutes-11-10-2016.md
(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 
OTTO.

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: 
http://kantarainitiative.org/confluence/display/OTTO/Home


More information about the WG-OTTO mailing list