User Metadata user-metadata
Introduction intro
The User Metadata feature enables Programmers to access different types of user-specific data maintained by MVPDs. User metadata types include zip codes, parental ratings, user IDs, and more. User metadata is an extension to the previously available static metadata (Authentication token TTL, Authorization token TTL, and Device ID).
User Metadata Key Points:
- Passed to the Programmer’s application during the authentication and authorization flows
- Values are saved in the token
- Values can be normalized if different MVPDs provide data in different formats
- Some parameters can be encrypted using the Programmer’s key (e.g. zip code)
- Specific values are made available by Adobe, via a configuration change
Obtaining User Metadata obtaining
User metadata is available to Programmers via the AccessEnabler getMetadata()
function and via the /usermetadata
endpoint in the Clientless API. Please refer to the platform API documentation for details on using getMetadata()
and its corresponding callback setMetadataStatus()
(or for the endpoints and parameters used in the Clientless API).
Programmers get metadata by supplying a key for the type of metadata they want to obtain: getMetadata(key)
.
The metadata is returned as follows: setMetadataStatus(key, encrypted, data)
:
key
encrypted
data
The structure of the data parameter, values vary between types:
zip
householdID
userID
maxRating
VCHIP: “X”,
URL: “http://manage.my/parental” }
userID
userID
will be different than householdID
.channelID
is_hoh
encryptedZip
typeID
primaryOID
typeID
is Primary, will contain the value of the userID
Important: The actual User Metadata available to a Programmer depends on what an MVPD makes available. Legal agreements must be signed with MVPDs before sensitive user metadata (such as zipcode) is made available in the production environment.
The hashing in this case was done for historical reasons
This ID could be a household ID or a sub-account ID. This is typically not specified, it’s just the ID tied to the login that was used at the time (which can be a primary one or a sub-account)
The ID can contain concurrency monitoring policies as well
For most MVPDs this value is equal to the User ID
It’s sometimes used as a Parental Controls substitute if true ratings are not available (If the user was logged in with the household account they can watch, otherwise rated content would not be displayed)
There is a lot of variation across MVPDs for how this is represented - household user ID, head of household ID, head of household flag etc.
Type ID = Flag that identifies if the user account is primary/secondary account
Primary OID = Household identifier. If TypeID is Primary, will contain the value of the userID
Has MPAA or VCHIP ratings
Please note that preflight authorization generally allows more flexiblity for this usecase and should be used instead
The OLCA specification allows for this as an AttributeStatement in the AuthN response
Can be also provided with the AuthZ resonse for fast updates
Sensitive data, needs MVPD legal agreements
Available Metadata available_metadata
The following table lays out the current state of user metadata in the Adobe Pass Authentication eco-system:
Agreement
Signed (zip only)
on AuthN
on AuthN/Z
on AuthN/Z
ID on AuthN/Z
userID
zip
maxRating
householdID
channelID
2. For AuthZ - There is no generic way, because authorization implementation is MVPD-specific
This is generic support for Synacor - possibly not rolled-up to all their MVPDs.
MVPDs
For all MVPDs, the User ID is available with no extra work.
The list of user metadata types will be expanded as new types are made available and added into the Adobe Pass Authentication system.
Code Samples code_samples
Code Sample 1 code_sample1
// Assuming a reference to the AccessEnabler has been previously obtained and stored in the "ae" variable
ae.setRequestor("SITE");
ae.checkAuthentication();
function setAuthenticationStatus(status, reason) {
if(status ==1) {
// User is authenticated, request metadata
ae.getMetadata("zip");
ae.getMetadata("maxRating");
} else {
...
}
}
// Implement the setMetadataStatus() callback
function setMetadataStatus(key, encrypted, data) {
if(encrypted) {
// The metadata value is encrypted
// Needs to be decrypted by the programmer
data = decrypt(data);
}
alert(key + "=" + data);
}
Code Sample 2 (Mock getMetadata) code_sample2
// Assuming a reference to the AccessEnabler has been
// previously obtained and stored in the "ae" variable
// Mock the getMetadata() method
var aeMock = {
getMetadata: function(key) {
var data = null;
// Set mock data based on the received key,
// according to the format in the spec
switch(key) {
case 'zip':
data = [ "1235", "23456" ];
break;
case 'maxRating':
data = { "MPAA": "PG-13", "VCHIP": "TV-14" };
break;
default:
break;
}
// Call the metadata status just like AccessEnabler does
setMetadataStatus(key, false, data);
}
}
ae.setRequestor("SITE");
ae.checkAuthentication();
function setAuthenticationStatus(status, reason) {
if (status == 1) {
// User is authenticated, request metadata using mock object
aeMock.getMetadata("zip");
aeMock.getMetadata("maxRating");
} else {
...
}
}
// Implement the setMetadataStatus() callback
function setMetadataStatus(key, encrypted, data) {
if (encrypted) {
// The metadata value is encrypted, so it
// needs to be decrypted by the programmer
data = decrypt(data);
}
alert(key + "=" + data);
}