Skip to content

Latest commit

 

History

History
79 lines (46 loc) · 5.52 KB

namespace.schema.md

File metadata and controls

79 lines (46 loc) · 5.52 KB
Raw

Namespace Schema

https://ns.adobe.com/xdm/context/namespace

Namespaces are used to scope end-user and device identities generated by different parties which need to later be linked or correlated. The namespace ensures first, second, and third party user and device identities can be used in customer engagement platforms. (Note: do not confuse identity namespaces with the JSON-LD namespaces used in describing XDM schemas.)

Namespaces are used to attain uniqueness with user and device identities that originate in distributed, uncoordinated identity environments. It can be thought of as an additional prefix that can be used to guarantee uniqueness between several generators of identities that are only otherwise guaranteed to be unique in the scope of the individual generating system (the standard case for cookies and integer based identities).

In XDM, end-user or device identities (represented by the Identity schema) are always scoped by a namespace.

This architecture assumes the following components:

  • The managing service is the system (for example, a customer engagement platform) that needs to manage and use identities flowing from different sources and from disparate parties.
  • The contributing service is the system (for example, a web site that places end-user cookies) that sends identities to the managing service to be managed or used.
  • The namespace service is the system that manages namespaces on behalf of the other services in order to allow them to share identities while ensuring uniqueness. It is often, but not always, operated as part of the managing service.

Within this architecture, identities may be shared with the managing service as follows:

  • The contributing service calls the namespace service and creates a new namespace. While the namespace service owns the namespace, the contributing service is responsible for giving it a name that is unique for itself. This name is called a "code". The namespace service is responsible for ensuring that each namespace created has a unique code within the context of the contributing service. For example, the namespace service may use the authentication credentials provided by the contributing service (or other mechanism) to identify the contributing service, and to ensure the code is unique within the set of codes provided by that service.

  • When sending end-user identities to the managing service (for example, when sending data via ExperienceEvent), the contributing service includes the namespace code on each identity.

  • When receiving end-user identities, the managing service stores, links, or otherwise uses the provided identities prefixed with the namespace code, ensuring uniqueness. The managing service should verify both that the namespace is valid and that the namespace was created by or owned by the contributing service.

A namespace code is used in lieu of a UUID or namespace service controlled identifier in order to integrate more easily with existing systems that generate end-user identities. These systems use many different schemes for managing uniqueness within their own domains. Often these codes are human-readable values that designate an account or contract.

While in the general case namespace codes are owned and managed by the contributing service, a namespace service may allocate its own namespaces with codes that might be used by multiple contributing services to send common identifies. Examples here include email addresses, phone numbers, or push notification tokens. Details on how a namespace service shares these global codes with a contributing service, or prevents them from conflicting with codes generated by contributing services, is not defined by this framework.

Related:

Namespaces are similar to datasources, both in the use of codes and in the assumed architecture for their use. The core difference being datasources are used to uniquely identify specific sources of general data in an uncoordinated data environment, such as independent data collection applications. These concepts are distinct because the source of data, and the source of the identities contained in that data, may not be the same.

Abstract Extensible Status Identifiable Custom Properties Additional Properties Defined In
Can be instantiated Yes Stable No Forbidden Permitted datatypes/namespace.schema.json

Schema Hierarchy

Namespace Example

{
  "@id": "https://data.adobe.io/entities/namespace/12345",
  "xdm:code": "AA12345"
}

Namespace Properties

Property Type Required Defined by
xdm:code string Optional Namespace (this schema)
* any Additional this schema allows additional properties

xdm:code

Code

The code is a human readable identifier for the namespace and can be used to request the technical namespace id which is used for identity graph processing.

xdm:code

  • is optional
  • type: string
  • defined in this schema

xdm:code Type

string