On-device sources of tokens?

[davidvancleve]

It seems like trust tokens could end up being scarce on the mobile web, because it's common for users to do things in apps on mobile that they'd do on the web on desktop.

This bug tracks potential work to extend issuance to on-device sources of tokens in order to make up for this absence.

[erik-anderson]

We discussed some aspects of this idea in https://groups.google.com/a/chromium.org/g/blink-dev/c/SlLdc64lvpM.

To make sure they're not lost, I'm moving the conversation here. Some questions/comments should probably get split into separate issues as this extension proposal gets more developed.

1. Should on-device tokens support private metadata which implies some part of the site has some form of contract with the platform owner to be able to decode the result? Or for interop reasons is the decision expected to always be public?

   Response from David:

   Depending on the setting, these tokens' meanings could be completely public and easily interpretable while still being useful. (Providing attackers an oracle into the result of the issuance process isn't necessarily a dealbreaker.)

2. For platforms where the OS doesn’t have native support but where the browser might be able to collect context and mediate with its own issuer to produce something equivalent, would the value in requestTokensLocallyOn be a name that is specific to the browser vendor (or perhaps the token creator if multiple browsers share one)?

   Response from David:

   If it seems like this could be a useful feature, we could conceivably change that field down the line to be something that the network and content layers don't need to interpret. The embedder could then make a decision whether to fulfill a given issuance based on the (issuer, requestTokensLocallyOn) combination.

3. How would issuers handle the case where they want to combine context they have along with the platform-provided context? Would they need to use two separate issuer endpoints? Or should there be a flow where the issuer can still also issue its own set of tokens and, at redemption time, the two different types of tokens would be provided concurrently?

   Response from David:

   I think this really boils down to the specifics of the mechanism for executing an issuance operation on device. Conceivably, this could happen in an environment where the issuer has some issuer-specific state available. If this isn't the case, then it seems like using two kinds of token could make sense: one with the issuer's state and one with the on-device state.

   Further thoughts:

   I'd like to understand this better. Are there any instances where the issuer and on-device token source would have issuer-specific state without the issuer being owned by the UA vendor itself?

Additional questions:

• To avoid unintentional name collisions, does there need to be a public registry of valid requestTokensLocallyOn values that defines who the on-device issuer is owned by?

• If the on-device issuance flow involves a networking call outside of the page context to produce a more meaningful trust signal, there may be scale concerns. Do we expect the origin doing the redemption to be passed to the on-device issuer to allow it to make a decision about if it wants to allow a redemption?

[davidvancleve]

I'd like to understand this better. Are there any instances where the issuer and on-device token source would have issuer-specific state without the issuer being owned by the UA vendor itself?

We're imagining this feature initially supporting sources of tokens that have some notion of "trust" or "privilege" at an OS or UA level, rather than (say) completely arbitrary native apps. (Notwithstanding permission prompts being the worst, on OSes with some kind of user-granted-permissions functionality, one kind of conceivable gate could be that this issuance is restricted to apps with a particular user-granted permission.)

If the source of tokens has this notion of trust or privilege, it's possible that it could have state common with a website. (For instance, if it had the appropriate level or trust or privilege, the "Popular Website" app could provide tokens corresponding to the issuing website popular.website.)

To avoid unintentional name collisions, does there need to be a public registry of valid requestTokensLocallyOn values that defines who the on-device issuer is owned by?

I wasn't thinking it would define who "owns" the on-device source of tokens, but rather which on-device entity maintains the issuers-to-trusted-on-device-sources mapping; did I misunderstand your initial question about this? In either case, a public registry seems like it could come in handy; thanks for the suggestion!

If the on-device issuance flow involves a networking call outside of the page context to produce a more meaningful trust signal, there may be scale concerns. Do we expect the origin doing the redemption to be passed to the on-device issuer to allow it to make a decision about if it wants to allow a redemption?

We were imagining redemption could happen via the same mechanism as for normal "web-issued" tokens; there's no reason in principle why it couldn't also take place through a device-local intermediary like for issuance, though. I think we'd probably want to have the information available at redemption time be pretty similar in both cases, including the redeeming origin.

[erik-anderson]

We're imagining this feature initially supporting sources of tokens that have some notion of "trust" or "privilege" at an OS or UA level, rather than (say) completely arbitrary native apps. (Notwithstanding permission prompts being the worst, on OSes with some kind of user-granted-permissions functionality, one kind of conceivable gate could be that this issuance is restricted to apps with a particular user-granted permission.)

If the source of tokens has this notion of trust or privilege, it's possible that it could have state common with a website. (For instance, if it had the appropriate level or trust or privilege, the "Popular Website" app could provide tokens corresponding to the issuing website popular.website.)

My question wasn't around arbitrary apps on the system providing these tokens though that's perhaps interesting as well.

If an issuer wanted to say that it wants to use system token provider X when available, I was imagining that the system token provider wouldn't generally have the same sort of context as the issuer unless the owner of the OS/UA-level token provider was the same entity (e.g. imagine a browser that has the same user login state context at both the UA level and in the current site's context).

If there are other entities with issuer endpoints that want to leverage OS-level state when available but would otherwise have their own trust logic via info available within normal web platform constraints at issuance time, it seems more likely than not that they would want to leverage context from both types of tokens during redemptions.

If the on-device issuance flow involves a networking call outside of the page context to produce a more meaningful trust signal, there may be scale concerns. Do we expect the origin doing the redemption to be passed to the on-device issuer to allow it to make a decision about if it wants to allow a redemption?

We were imagining redemption could happen via the same mechanism as for normal "web-issued" tokens; there's no reason in principle why it couldn't also take place through a device-local intermediary like for issuance, though. I think we'd probably want to have the information available at redemption time be pretty similar in both cases, including the redeeming origin.

This makes sense if the on-device token issuer is owned by the same entity as the issuer service. If the issuer is not the same, though, how can the on-device issuer throttle/control who it hands the tokens out to?

My question might be more of an implementation question: for the on-device tokens, would we expect the document.hasTrustToken call to result in a check with the on-device token issuer to determine if it wants to allow the token to be consumed? And, if so, what concerns might we have where the normal/non-on-device issuer would prefer to fall back to issuing its own tokens if the on-device token source decides to throttle redemptions associated with that issuer?

I think the root of a number of my questions can be boiled down to needing to better understand what pre-existing relationship, if any, is there expected to be between the entity that owns the issuer that specifies it wants to use on-device tokens and the owning entity of the on-device token source?

[davidvancleve]

(Agh! Lost my draft because my computer crashed.)

If there are other entities with issuer endpoints that want to leverage OS-level state when available but would otherwise have their own trust logic via info available within normal web platform constraints at issuance time, it seems more likely than not that they would want to leverage context from both types of tokens during redemptions.

I agree this could be the case some of the time. Depending on the different types of web- and device-issued tokens out there, I'd think consumers, constrained by the per-site limit on the number of associated issuers, which in particular limits the number of types of token one can redeem, might sometimes want to consume a mix of web- and device-issued tokens and sometimes might want to use entirely one or entirely the other.

I think the root of a number of my questions can be boiled down to needing to better understand what pre-existing relationship, if any, is there expected to be between the entity that owns the issuer that specifies it wants to use on-device tokens and the owning entity of the on-device token source?

I think it's simplest to expect them to always be the same, at least initially.

If it were possible to execute redemption on device, we could conceivably support behavior where you have web-issued davids.website tokens with one meaning, and separately davids.website/keys.json contains configuration that specifies "Please request tokens locally on Android [from some other source of tokens operated by some other entity] when possible, and treat these tokens as if they'd been issued from a request to my issuance endpoint". This seems potentially useful, if complex to use (you might need to switch on OS when interpreting the tokens' embedded information), but it isn't a behavior we're currently planning on including in our initial design.

This seems harder to support without on-device redemption, because redeeming the tokens would require some server-to-server communication: the davids.website redemption endpoint would need to know how to contact the entity that actually issued the tokens and request a redemption, since tokens requires the issuing entity's token issuance keys. (There are some variants of the underlying cryptographic primitives that could allow verifying the tokens' validity without possessing the token issuance keys, so this isn't a firm constraint in the long run.)