Use case requirements - service profile registrar models

Dale and others,

Thank you for what I thought was an excellent overview of requirements across the different process steps and architectural layers that we’ve discussed. Thanks too for your detailed review of relevant efforts in these areas from IETF and elsewhere. You closed by suggesting that it would be helpful to have some discussion of “who” will run these services, and “how” they will verify registrations as legitimate. I’d like to share some thoughts I’ve had about these questions, as well as issues of “service profile composition” and “conflict resolution” that I see potentially arising.

As we discussed, there are different scenarios and requirements that arise at the high and low ends of the “security / governance” spectrum. At the high end, an enterprise or a bank might have a tightly managed service profile, tightly coupled with its corporate domain DNS record. At the low end, a service profile and its related locator records might be associated just with an email address, and provisioned through one specific service provider. I will focus first on the latter “low end” case, although I see some of these issues perhaps flowing over into the “high end” case as well.

In general, we can identify the following classes of provider involved. (These may map to either an ‘SML’ or ‘SMP’ role, but perhaps not cleanly and uniquely in all cases):

1. One or more service providers / access points having a (possibly pre-existing) service relationship with an SMB, (e.g. or e-invoicing solution provider, an accounting software vendor, a bank);

2. One issuer of an identity used by the SMB, which issuer may or (more likely) may not have taken any action to participate in this proposed architecture (e.g. a user email issued on a specific domain, a user-specific domain issued through a registrar, a national or global organization id scheme (DUNS etc));

3. One or more providers of lookup services relating to one or more such identity schema (who may or may not also publish metadata);

4. One or more “community root” providers (e.g. PEPPOL), aggregating service locator records for all users within a specific, known, functional/geographical community.

5. One “global root” directory across all such providers, as with DNS, governing the propagation of identity records. (Or, possibly, one for each identity schema, possibly operated under contract to the issuer of the corresponding identities).

Often, and especially with SMBs, the number of users enrolled correlates to how easy that enrollment process is. So, (technology permitting), we may see some service providers with large existing user/customer bases that offer a “one-click” or “checkbox” enrollment process for those users/customers. Through such a one-click enrollment, an SMB user agrees to have the provider publish on their behalf a service profile record that indicates at least *availability* of a certain set of process interactions supported by that service provider. This is not necessarily the same as *enrollment/activation* of all those process interactions: that step may be triggered only upon receipt of the first invitation or request from a partner relating to a specific process interaction identified in the published record as being *available*.

This kind of easy enrollment process implies a relatively low level of user awareness as to their newly-published profile of “available process interactions”, associated with this specific service provider. Indeed, it becomes likely in some cases that a single end user (in this use case, identified by just an email address) would so authorize more than one service provider.

In some cases, those service profiles might be entirely complementary (e.g. send my orders here, send my invoices here, send payments here with three different providers). In those cases, there would need to be some mechanism for a third party wishing to interact with that user to retrieve a “composed profile” including the various available services and their corresponding endpoints (through different service providers). In some other cases, however, conflicts may arise where two of those profile records from different providers overlap. Resolving this requires an answer to the question: “which service provider should be used to interact with you for this specific process?”.

At least in this email case, I see at least two potential scenarios.

1. As with a domain registration, the first service provider becomes THE SOLE registrar and manager of the profile associated with that user (here, an email address). Subsequent registration requests from third parties (i.e. new service providers) would need to follow an agreed protocol to either:

a. Transfer control of the entire profile record to the new provider/registrar, or

b. Negotiate inclusion/composition of the new provider’s proposed profile records with the existing profile. This would be easy in the ‘no overlap’ case, but potentially problematic where there was an overlap. This problem could be mitigated by having providers submit profile update requests in logical groupings to be accepted or rejected in toto based on whether there was an overlap or not. Best practice / governance agreements could require that service providers present those options to users, rather than just rejecting requests from what might be, in some cases, competitive service providers.

2. Alternatively, the profile registrar might maintain a relationship with the user separate from that of the service provider who generated the original registration (via distribution agreements and perhaps with appropriate service branding to the end user). Profile change requests from new service providers would need to be handled as described above. But for the registrar entity concerned, this profile maintenance role would a core part of their business, as distinct from the provider focused on provision of services for which publication of the profile is a means to an end.

The first of these seems closer to today’s domain registrar model. However, in business terms, it seems likely that most service providers would not want to take on the burdens and obligations that would go along with being a registrar, i.e. profile management, negotiating profile updates from third party providers etc. So this model seems to me more plausible, at least as an end-state.

The case described so far discussed profile creation/registration tied to an email address. However, we can extend this framework in a couple of ways to enable incrementally greater levels of trust in a published profile. Just to mention briefly a few of those notions:

1. “Locking” of profile governance at higher levels, a notable example being of “locking” at the “domain.tld” level to govern “email@domain.tld” profiles.

2. “Verified Association” of a single profile with multiple identities (e.g. company identifiers, bank accounts), where a USER ACCESS AND ACTION is required to verify and authenticate the association (e.g. an email approval link sent to a domain’s listed administrator; verification of bank account access by confirmation of the amounts of small test transfers)

3. “Anchoring” to a trusted identity (a subset of associating), where an explicit CHANGE is required in the trust anchor system to designate trust in the profile by pointing to it from an existing public record associated with that trusted identity. A notable case here would be of a change to an organization’s regular domain or subdomain DNS record to point to the profile.

There’s doubtless more to say about the various scenarios I’ve touched on here, but this seems like a long enough email on the topic for now.

Regards,

Roger

bdxr message