[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [bdxr] This weeks meeting
Thank you both for this, and Pim for chairing tomorrow’s meeting in Kenneth’s absence. I will see about incorporating your document into the wiki use cases, but it seems good that you shared your document directly with the TC.
I’d add a comment to yours below, Pim: in your first, ‘between service providers’ case below, the issue still arises as to how service providers agree to trust one another, notably including the agreed mechanisms by which they authenticate their own users to ensure that only ‘valid’ Connect requests are passed through on the network. Those trust relationships could be bilateral, but most likely end up as part of some kind of multi-party Trust Framework (which might well include, as PEPPOL does, a CA). So the difference between your two scenarios seems to me to be partly about each of the following:
a) whether the parties operate these authentication mechanisms themselves versus using a service provider as their agent
b) the different trust framework / mechanisms between the parties (or their service providers agents), and underlying that
c) the different mechanisms for trusting / authenticating a user.
See the Id Cloud Intercloud Use Case document, Scenario 3 (Inter-cloud Trust Establishment) for some further thoughts on this. At some point I’ll try to incorporate any relevant thinking from there, along with your document Pim, into revised use cases on the BDX wiki. Some notions there that seem to me relevant here are:
· Trust Framework: whether bilateral, between service providers, or a broader, multi-party governance structure such as PEPPOL
· Trust Levels: levels of user verification / authentication that a service provider (or CA issuing end user certificates) implements as part of its Trust Framework Agreement(s), e.g.
o “Basic, Direct”: verification of an addressable id (email, bank account) by delivery of a token or link to that address. Clicking the link or reporting back the token value demonstrates ownership.
o “Basic, Indirect”: verify ownership of other ids by emailing a link to an email address associated with that id in a public profile (e.g. webmaster email for a domain; company email from a DUNS profile etc)
o “Strong”: verification of ownership of a domain by the existence of a DNS record published under that domain
· Availability/Activation Status: whether the user confirms the existence of a live, back-end process corresponding to a public delivery channel / process (perhaps even a more granular ‘service level’ assertion)
Security of the registration service is the hardest as (by definition) it involves communication among two partners that do not yet have any established relation, including established trust. Two options are:
- Rely on established trusted relations between service providers that relay Connect requests, so that you do not get registration requests directly from an unknown business partner, but via your service provider. The mechanism you use to trust you service provider is part of your service agreement with that provider..
- Rely on a mechanism by which entities authenticate using TLS authentication and certificates signed by a CA trusted for Connect messages. Any certificate signed using this CA is trusted and the entity identifier are extracted from the certificates. Which CA (or CAs) this is, would depend on the community to connect. PEPPOL acts as a CA for service providers in public e-procurement, Odette is a dedicated CA for automotive B2B, etc.
PEPPOL uses a combination of the two. The attached document (which I sent to Roger who is editing the use cases for the Connect protocol, but only today so he hasn't had any time to process it) has some discussion.
Thanks Pim for helping Kenneth out.
I would like to add some specifics to the DDDS discussion agenda.
I would like to hear some discussion of what a registration service that has the purpose of establishing credentials for access to a metadata service should do. To do this, some requirements concerning what access and authorization features are needed for a protected metadata service need to be proposed and discussed.
Sorry you can't make it, I'd be happy to host the call.
1) Dale's DDDS document
2) Updates to use cases
3) F2F agenda and preparations
4) Updates from related projects and activities
Because of illness I am unfortunately unable to participate in this weeks TC meeting. If anyone can step in and host the call I can provide you with the Gotomeeting credentials.