[WG-OTTO] OTTO WG Minutes 10/21

Janusz Ulanowski janusz.ulanowski at heanet.ie
Thu Oct 22 05:00:21 CDT 2015


On 22/10/15 10:24, Rainer Hoerbe wrote:
>
>> Am 22.10.2015 um 11:14 schrieb Janusz Ulanowski <janusz.ulanowski at heanet.ie>:
>>
>> Hi,
>> Thanks Rainer, that's very usefull informations.
>> First of all I think we should create some kind of glossary with very precise definitions of the jargon we use,
>> so there won't be any misinterpretations:)
>>
>> About Judith's proposal to use json-ld  - this very good one! - it'll give us flexibility so we should stick with it.
>
> After turtle and n-triples I still have to learn the advantages of a new RDF serialization. But I take it as given that anything starting with JSON is a progress.
>
>>
>> Rainer, about you last mail. I think I get a picture if entity is member of one Federation but not if I can see it in multiFederation. Would you be able to make simple picture ?
>
> Multiple FOs would simply publish assertions that the organization is member of a federation. BTW, I think that the approach of SAML MD to describe only technical entities instead of legal operators is moving the (workflow-wise) difficult problems to out-of-band resolution. That is why I described the model admin <-> org <-> domain <-> entity.
>
>>
>> I'm also curious also  how would it look like  if client (for instance RP) has hardcoded (trusted source/federation url etc) and joins other federation (it was one of reasons to add memberOf, homeFederation and seperate entity metadata from federation one)
>
> Hmm, if it is really hard-coding there will be a need for some kind of gateway I guess.
>
I still think it's worth to consider such scenario - it would be like 
following graphs.
In Edugate we introduced circle of trust metadata. SP/IDP admin had to 
only set individual URL as source of metadata (SAML profile) and that's 
it. Later he can manage membership of any federation (including Edugain, 
campus federations, biliteral etc) on our ResourceRegistry without 
changing anything on his software configuration. such approach is very 
appreciated by our members.

>>
>> btw is anyone going to EWTI in Vienna?
>
> I hope that we will have a good discussion on OTTO.

See you in Vienna:)


> - Rainer
>
>>
>> All the best,
>> Janusz
>>
>> On 22/10/15 08:53, Rainer Hoerbe wrote:
>>> In yesterday’s call we discussed the point to what extent assertions
>>> would be specific to OAUTH, SAML or PKIX. I said that it would be good
>>> to share more generalized assertions and extend that super-schema with
>>> more specific things. I would like to provide some examples:
>>>
>>> # 	Authoritative source 	assertion
>>> 1 	CA, registrar 	organization (org) A is owning domain X
>>> 2 	Org A 	org B n is providing services for org A
>>> 3 	Org A 	person owning key K1 is administrator for entities in A
>>> 4 	FO in federation F 	Org A is member in federation F in good standing’
>>> 5 	WoT, out of band 	FO in federation F has signing key K2
>>> 6 	Org A's NREN 	Org A is categorized as entity category R&S
>>> 7 	IDP Y's operator 	IDP Y has the public key K3
>>> 8 	Assessor S 	IDP Y has been certified to support LoA3
>>> 9 	Kantara 	Assessor S is accredited assessor
>>> 10 	Kantara 	Kantara is trust framework provider
>>>
>>>
>>> 	
>>>
>>>
>>> I think that the entries in the public ledger should contain or
>>> reference generic notations of the claims or assertions. Linked data
>>> triples seem to be a suitable format, that could be used to generate
>>> technology-specific formats.
>>>
>>> A domain-validated X.509 certificate with „domain X“ in the subject-DN’s
>>> CN could be issued to Org A based on assertion 1. That certificate could
>>> be issued to Org B based on assertions 1 and 2.
>>>
>>> To create a SAML EntityDescriptor for IDP Y an entity in federation F
>>> would use assertions 1-10 plus the check that domain X is contained on
>>> IDP Y’s entityID and endpoints.
>>>
>>>
>>> Assuming that we have a ledger with a collection of useful assertions,
>>> there are 2 main approaches to process them.
>>>
>>> A. Local "database". Some (trusted) code would generate a local data
>>> store (a graph/triple-DB, SAML metadata aggregate, X.509 key store,
>>> XML-based trust list) based on this information. This would be either
>>> versatile (the graph version) or compatible with a specific purpose
>>> (SAML, X.509, ..). New entries in the ledger would update the local data
>>> store. For added security a backlink to the ledger could be used to
>>> protect against corruption.
>>>
>>> B. Looking up assertions in the ledger on the fly. For that purpose the
>>> triples would have to be added in reverse order as well to support
>>> searches on the right part of the triplet.
>>>
>>> Regarding confidentiality and payment I think that this should not be
>>> handled on the level of the public ledger, because having multiple
>>> ledgers would mean  that claims would have to go into multiple ledgers
>>> because of the unavoidable overlaps. In principle I do not see a problem
>>> in having references in the ledger and assertions behind a
>>> authentication scheme or paywall.
>>>
>>> -Rainer
>>>
>>>
>>>
>>> _______________________________________________
>>> WG-OTTO mailing list
>>> WG-OTTO at kantarainitiative.org
>>> http://kantarainitiative.org/mailman/listinfo/wg-otto
>>>
>


More information about the WG-OTTO mailing list