[WG-OTTO] OTTO WG Agenda Tomorrow 11/10

Keith Hazelton keith.hazelton at wisc.edu
Wed Nov 11 11:00:04 CST 2015

As mentioned at the end of the call:

examples of metadata elements needed in otto-land:

UMA well-known config url: https://docs.kantarainitiative.org/uma/draft-uma-core.html#am-endpoints 
https://accounts.google.com/.well-known/openid-configuration  <== concrete example

email & jabber: keith.hazelton at wisc.edu
calendar: http://go.wisc.edu/i6zxx0
On 2015-11-10, 14:33 , "wg-otto-bounces at kantarainitiative.org on behalf of Mike Schwartz" <wg-otto-bounces at kantarainitiative.org on behalf of mike at gluu.org> wrote:

>I really like the requirements doc:
>I think we should discuss this in detail tomorow, especially as it 
>relates to JSON linked data. This video was really nicely done: 
>http://gluu.co/json-ld-intro-video  And there seems to be a link between 
>JSON linked data, and triples as you mention in your doc. I'm guessing 
>something like : (entity ABC, belongs, federation XYZ)
>I think we all like the idea of the blockchain, its the implementation 
>that is so unclear. I'm concerned that if we don't consider the 
>blockchain publication method, we may miss something important in the 
>design of the schema. But I get caught up on details like "which 
>blockchain." And what's the business model.
>With the linked data approach more concrete, I think we can map out how 
>to connect to a blockchain, probably the Bitcoin blockchain, which is 
>the most active. I guess we'll just have to figure out how to do this...
>- Mike
>On 2015-11-10 14:10, Rainer Hoerbe wrote:
>>> Am 10.11.2015 um 18:34 schrieb Mike Schwartz <mike at gluu.org>:
>>> Just a reminder about the meeting tomorrow at 8am PT.
>>> I think we should discuss putting the blockchain idea on the back
>>> burner and focus on the schema. I'm hoping this would enable us to
>>> work in parallel to resolve some of the many questions around how to
>>> best use the blockchain technology.
>> I agree to put the implementation questions of blockchains aside for
>> the time being. However, we should come to a consensus about the
>> higher-level concept of a distributed public ledger.
>> To recap: Traditional patterns to establish trust use trusted third
>> parties who register and sign factoids, frequently from multiple
>> authoritative sources. This proof of correctness is a well-established
>> practice, as exemplified in this document [1] that testifies that my
>> grand-grandfather had fulfilled his military service by 1847,
>> including his name and place and date of birth.
>> A public ledger is different in that does provide _continuity_ instead
>> of _correctness_. Binding a name to a key, or more general claims, are
>> trustworthy because a claim is public and cannot be altered or revoked
>> without the public noticing it. Combined with the requirement of the
>> claim author and/or subject for an on-going monitoring of their
>> respective claims there is a guarantee that facts cannot change
>> unexpectedly, and cannot be censored either.
>> Besides this difference there is also an advantage for a public ledger
>> in that it is not owned by a particular operator. Of course, there is
>> the development team and other stakeholders, but this is much more
>> transparent and distributed than a traditional CA, notary, bank,
>> government register etc. While a TTP has a specific scope in their
>> business model, public ledgers can accommodate multiple domains,
>> business models, jurisdictions and assurance levels, allowing for
>> re-use of assertions.
>> A combination of the traditional TTP-model with a public ledger would
>> therefore achieve a higher and more scaleable way of sharing trust
>> assertions. Third-party assertions will address the problems of trust
>> on first use, DoS, lack of monitoring, link to legacy trust sources.
>> The public ledger will provide irrefutable proof of continuity.
>> I started with a draft requirement document that includes the thoughts
>> above:
>> https://github.com/KantaraInitiative/wg-otto/blob/master/docs/sources/requirements/requirements.md
>> [2]
>> Cheers, Rainer
>> PS: Apologies for tomorrow: I will be with a customer tomorrow an
>> won’t make the call.
>> Links:
>> ------
>> [1] http://files.hoerbe.at/stammbaum/CarlConradMeier18471027.jpg
>> [2]
>> https://github.com/KantaraInitiative/wg-otto/blob/master/docs/sources/requirements/requirements.md
>Michael Schwartz
>Founder / CEO
>mike at gluu.org
>WG-OTTO mailing list
>WG-OTTO at kantarainitiative.org

More information about the WG-OTTO mailing list