[WG-OTTO] OTTO WG Minutes 10/21
janusz.ulanowski at heanet.ie
Fri Oct 23 05:20:49 CDT 2015
On 22/10/15 10:14, Janusz Ulanowski wrote:
> 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,
> 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
>> 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.
>> WG-OTTO mailing list
>> WG-OTTO at kantarainitiative.org
> WG-OTTO mailing list
> WG-OTTO at kantarainitiative.org
More information about the WG-OTTO