[WG-OTTO] OTTO WG Minutes 10/21

Janusz Ulanowski janusz.ulanowski at heanet.ie
Thu Oct 22 04:14:23 CDT 2015

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.

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 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