[WG-OTTO] Draft Minutes 8/19/15

Mike Schwartz mike at gluu.org
Fri Aug 21 09:51:36 CDT 2015


Janusz,

That's what I was thinking... similar to how in LDAP you can link to the 
DN of another entry.

Instead of using a list, maybe use a dictionary with the id as the key? 
Or would that not be supported by the blockchain metadata distribution 
strategy we are considering?

{ '1234': {"type": "fed",
            "trust": ["321", "421"],
            "acrs_supported": ["http://sample-fed.org/acr/password"]
            "amrs_support": [],
            "user_claims_supported": [],
            "openid_scopes_supported": [],
            "uma_scopes_supported": []
           }
  }


> Maybe during entity registration copy of public key of entity would be
> stored by RegistrationAuthority.
> It could be used by api to verify change requests.

I like this idea too... makes sense.

- Mike

On 2015-08-20 18:30, Janusz Ulanowski wrote:
> Hello,
> 
> I'm just wondering....
> What about using di-graph structrue for representation metadata.
> Metadata could be flat containing additional information about trust.
> [
>     {
>         "type": "fed",
>         "id": "234234",
>         "trust": [
>             "321",
>             "421"
>         ]
>     },
>     {
>         "type": "rp",
>         "id": "321",
>         "trust": [
>             "234234"
>         ]
>     },
>     {
>         "type": "as",
>         "id": "421",
>         "trust": [
>             "234234"
>         ]
>     },
>     {
>         "type": "as",
>         "id": "555",
>         "trust": [
>             "666"
>         ]
>     },
>     {
>         "type": "rp",
>         "id": "666",
>         "trust": [
>             "555"
>         ]
>     }
> ]
> 
> (trusts could be seperated nodes with diffrent type)
> maybe it could also contain degree of trust etc
> 
> This structure could allow to set multi-fed trust, bi-literal.
> and trust between nodes must best on both ends.
> The calculation would be bit more complex to check trust between
> paries through fed(s) - (graphs theory to revisit)
> ... and we can still use blockchain - i guess
> 
> 
> # How would the federation give access to members to write to a tree?
> 
> Maybe during entity registration copy of public key of entity would be
> stored by RegistrationAuthority.
> It could be used by api to verify change requests.
> 
> 
> 
> On 19/08/15 17:19, Mike Schwartz wrote:
>> OTTO WG Minutes 8/12/15
>> STATUS: Draft
>> 
>> ## Voting Members Attending:
>> Michael Schwartz
>> Judith Bush
>> Keith Hazelton
>> Jim Willeke
>> 
>> ## Non-voting members
>> - Rainer Hoerbe
>> 
>> ## Topics discussed
>> 
>> NOMINATIONS / VOTING
>> We will open nominations for roles the week of 9/2 - 9/8, hold voting
>> the week of 9/9-9/15.
>> Roles will be two co-chairs and specification editor. Need to 
>> follow-up
>> to ask
>> about if there is a system available to handle our vote.
>> 
>> 1) Scope / Schedule
>> 
>> Entity discovery is the most important use case:
>>    1) How would the federation give access to members to write to a 
>> tree?
>> 
>>    2) Entity / member data structure?
>> 
>>    3) Federation description data structure? Is it just an entity?
>>        a) How a federation would publish what user attributes, openid
>> scopes,
>>         uma scopes, acr's and amr's are available?
>> 
>>    4) How will the data be published--blockchain
>> 
>>    5) How can you query? By id? What about entity-based attribute 
>> based
>> queries?
>>       For example, return all the OpenID Connect Relying Parties. 
>> Rainer
>> mentioned
>>       perhaps a query to return RP's with a certain sector_identifier.
>> 
>>    6) Description of the trust models : hierarchical, peer-to-peer. 
>> How
>> would trust
>>    be established using the OTTO data structure / standard.
>> 
>> Metadata publication is a solution to a larger problem, for example,
>> business rules, enrollment.
>> 
>> Peer to peer trust models exist for certificates, where you could see
>> who else trusts an entity.
>> Replication rating in stack exchange... or social network.
>> 
>> Perhaps if there is visibility on who trusts who, it could enable the
>> creation of many trust models.
>> 
>> Jim posted a link to an article on a minimum viable blockchain:
>>   https://www.igvita.com/2014/05/05/minimum-viable-block-chain
>> 
>> Rainer mentioned that we need to consider the time aspect of any trust
>> network. For example, maybe I trusted
>> you last week, but not this week.
>> 
>> 2) OpenID Connect Thread on "claims" in the Client Registration Spec?
>> http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20150810/005680.html
>> 
>> 
>> 
>> -------------------------------------------------------------------------------------
>> 
>> 
>> Next week's Meeting Details - same time / same place!
>> 
>> -------------------------------------------------------------------------------------
>> 
>> 
>> Screen Sharing: https://global.gotomeeting.com/join/162399285
>> 
>> Audio: Skype: +99051000000481
>> North America Toll: +1 (805) 309-2350
>> Alternate Toll: +1 (714) 551-9842
>> International Toll: http://www.turbobridge.com/international.html
>> 
>> Conference ID: 613-2898
>> 
>> Command Menu: 0 Plays menu of Keypad Commands *3 Promote to Host (if
>> non-host) *5 Raise your hand *6 Mute yourself
>> (toggle on/off) *# Private roll call of participants *\ Mute
>> music-on-hold (toggle on/off)
>> 
>> TurboPhone (beta): https://www.turbobridge.com/join.html Works with
>> Internet Explorer on Windows only
>> 
>> SIP Access (using IP phone or soft phone) sip:bridge at turbobridge.com
>> SIP URL details: 
>> https://www.turbobridge.com/help/Index.html?context=180
>> 
>> _______________________________________________
>> WG-OTTO mailing list
>> WG-OTTO at kantarainitiative.org
>> http://kantarainitiative.org/mailman/listinfo/wg-otto
> 
> _______________________________________________
> WG-OTTO mailing list
> WG-OTTO at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-otto

-- 
-------------------------------------
Michael Schwartz
Gluu
Founder / CEO
mike at gluu.org


More information about the WG-OTTO mailing list