Criteo Is Ready To Test The Single Sign-On Software For Unified ID 2.0

SSO is a critical piece of the puzzle if UID 2.0 has any chance of reaching scale.

Criteo has started testing the single sign-on (SSO) solution – called OpenPass – that will serve as the consumer-facing component of Unified ID 2.0, the open source industry initiative that aims to use email as an alternative to third-party cookies.

In November, Criteo was one of the first companies to join Unified ID 2.0, which is being spearheaded by The Trade Desk, with the task of building an SSO interface and a transparency portal.

Criteo is handling most of the testing among users and publishers in GDPR countries, while The Trade Desk will conduct testing in the United States.

SSO is a critical piece of the puzzle if UID 2.0 has any chance of reaching scale.

Participating publishers will need to clearly explain why they’re asking for consent and what their visitors will get in return for sharing their email address – and “Gimme your data so I can target you with ads and you don’t have to pay” probably isn’t a compelling enough value proposition in the long term.

“We’re looking to improve the overall value of a person’s internet experience and not just create a safer way to personalize an ad,” said Todd Parsons, Criteo’s chief product officer. “Achieving that is relevant for our business and for the entire industry.”

Come to pass

Exactly what that souped up value exchange will be is TBD – and up to the publisher – but the one thing that’s non-negotiable about the SSO mechanism itself is that the experience has to be simple, consumer-friendly and as frictionless as possible.

Criteo is testing multiple variations of the SSO with publishers and users, including a logged-in experience with verification and an unlogged traffic experience for people that agree to see personalized advertising but don’t want to share their email address.

In the first scenario, users are presented with a pop-up module prompting them to enter an email address and a verification code that’s sent to their inbox. Once they do, they can continue to the site.

Meanwhile, in the backend, the domain passes the email address to the UID 2.0 service, which returns a hashed identifier that is stored on the client-side as a first-party cookie so that other websites can recognize the ID.

The next time those already opted-in users visit a website in the UID 2.0 network, they’re hit with another OpenPass pop-up that’s prepopulated with their email address. All the user has to do at that point is click “continue” in order to visit the site.

But, of course, not everyone is going to share an email.

For those who don’t want to authenticate but are willing to see targeted ads, a pop-up module asks them to agree to the OpenPass terms, including that a pseudonymous ID that doesn’t personally identify them will be shared with “trusted advertisers.” (Perhaps not the most user-friendly language of all time, but anyway … )

From there, users can continue onto the site and a unique identifier in the form of a non-PII alphanumeric string is generated on the backend.

Similar to the logged-in experience, the ID is stored on the client side by the SSO domain as a first-party cookie that can be read and recognized by other sites that users visit during their browsing session.The logged-in and unauthenticated OpenPass experiences.

An open exchange

Still, many open questions remain.

How will OpenPass work with existing sign-on solutions, like Auth0, and will it be interoperable with more nascent efforts, like SWAN.community (Secure Web Addressability Network), a global consent mechanism for anonymous browsing? Will the OpenPass technology support identity initiatives beyond Unified ID 2.0? And will publishers that have a first-party relationship be able to access a user’s actual email address or just the hashed UID 2.0 token? What type of SSO user experience drives the highest opt-in rate?

These were all topics of conversation at the first meeting, held last week, of a new project management committee devoted to the sign-on experience hosted under the auspices of Prebid.org. Members of the committee, chaired by Parsons, include representatives from around 50 publishers and ad tech companies. Parsons is currently looking for a publisher co-chair so that all interests are represented.

The next meeting will take place on Tuesday, April 6, and over the next week or so, the committee will finish preparing the OpenPass code and add it to a new GitHub repository.

Although there’s still a lot that’s unsettled about how identity will function on the open web, there’s no reason everything can’t coalesce in a manner that makes sense for businesses and for the user experience. It just requires collaboration.

For example, Parsons said that he’d be open to merging the OpenPass project with SWAN.community, which focuses exclusively on non-logged in browsing, if that effort ends up being as transparent and open as advertised.

“I mean, why not?” Parsons said. “We all need to put our self interests aside and try to build something that’s better for the consumer.”

Enjoying this content?

Sign up to be an AdExchanger Member today and get unlimited access to articles like this, plus proprietary data and research, conference discounts, on-demand access to event content, and more!

Join Today!

2 Comments

  1. A bit confusing this part:
    "Meanwhile, in the backend, the domain passes the email address to the UID 2.0 service, which returns a hashed identifier that is stored on the client-side as a first-party cookie so that other websites can recognize the ID."
    Which *domain* passes the email address to the UID 2.0 service?
    Does the "UID 2.0 service" coincide with "OpenPass"?
    Let's take a real example:
    As a user, if I visit Publisher1 website, this pop-up window for the SSO (OpenPass) is loaded as another different site or as publisher1 site?
    Let's assume it is served as publisher1 site, i type in my email (first time) and my email gets sent to the openPass system which send an hashed identifier to the publisher1 site so that it can set a first party cookie on my browser.
    Then i visit publisher2 site. How will publisher2 site be able to pre-populate the SSO form? Obviously it cannot read the first party cookie set by publisher1... so i will probably need to type in again my email address and get it sent to the openPass and at that point openPass will be able to recognize my email and send the same hashed identifier to publisher2 so that publisher 2 can set first party cookie.
    But all of this sounds not really what is supposed to be... it sounds too complicated and not just 1 click process.

    so it is not clear how this all work in reality, and would be great to give a real example with real names to publishers and clearly identify what is openPass , what is UID 2.0 service, and how can other publishers prepopulate the SSO form if i have never visited their site...

    seriously, need to be clearer... i feel it is really confusing now...

    Reply
  2. Other story if the first party cookies are set both from UID 2.0 (centralized) and the publishers. Assuming that when a user land on publisherX site the first thing that happen is the popuo module served DIRECTLY by UID 2.0 service (AKA OpenPass). I see this as the only way it could work. Thanks.

    Reply

Add a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>