[WG-OTTO] OTTO WG Minutes 10/21

Janusz Ulanowski janusz.ulanowski at heanet.ie
Fri Oct 23 05:20:49 CDT 2015


On 22/10/15 10:14, Janusz Ulanowski wrote:
> 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.
>
one more thing:
with linked data we need to remember to distinguish links to follow 
during request to receive complete data


> 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 ?
>
> 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)
>
> btw is anyone going to EWTI in Vienna?
>
> 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
>>
> _______________________________________________
> WG-OTTO mailing list
> WG-OTTO at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-otto


More information about the WG-OTTO mailing list