SIOP Credential Wallet as a PWA

[Kristina Yasuda]

In the attached document please find flows from Kim Cameron that show why a SIOP PWA is not an anonymous codebase and provides claimed integrity guarantees.

On page two, the actual redirect that requests the token is included. Hopefully, this makes it clear why the redirect must have reached the PWA if no certificate error has been received and the PWA has a valid codebase that can be downloaded by anyone who wants to inspect code as part of a reputation process.

[Tom Jones]

It needs to be pointed out that the relying party has no access the code actually run by the user agent and so cannot get any level of assurance from it.

Also this “reliability” probably cannot meet the criteria of the US HHS ONC on apps certified to download user health information.

According the the spec there is no way to determine if the key is hardware protected. That may be addressed in other docs that i have not seen.

[James Manger]

Thanks for showing these flows, Kim.

In the examples, itsyourweb.org provides wallet software as a progressive web app (PWA). Presumably the PWA asks the user's browser to generate a key-pair; hopefully hardware-backed; perhaps requiring the user's device-unlock gesture for each operation with the private key; and maybe with an attestation (chaining back to the O/S vendor and/or device vendor) that the key has these protections. The PWA will use the private key to sign SIOP responses.

A user with such a wallet can only use it at RP that explicitly supports this specific wallet vendor; ie an RP that lists itsyourweb.org alongside, say, Facebook & Google as supported OPs in a NASCAR-style list of logos. In the example, Air Canada (the RP) shows a QR code specific to itsyourweb.org (not any other SIOP).

An RP doesn't get any assurance that a user is running the true itsyourweb.org wallet. The user could have installed their own root CA and their own DNS settings pointing itsyourweb.org to their own site. But, under the assumption that a user is running a "normal" browser on a "normal" O/S, the RP can assume the itsyourweb.org wallet is running, with all the protections and consent screens that itsyourweb.org is trusted to implement. That may be sufficient for an RP to show a duty-of-care towards users by only supporting quality wallets.

Perhaps in future attestations from the O/S vendor about the state & identity of a PWA will be possible, much like an Android SafetyNet attestation from Google gives some assurance about a mobile app.

[Tom Jones]

I suppose the documentation may be out-of-date - if so i would like to find up-to-date docs, but right now it says: “While it is assumed that most user agents will be interacting with a cryptographic provider that is implemented purely in software, it is not required by this specification. As a result, the capabilities of some implementations may be limited by the capabilities of the underlying hardware, and, depending on how the user has configured the underlying cryptographic library, this may be entirely opaque to the User Agent.” https://w3c.github.io/webcrypto/

[Nat Sakimura]

To be discussed on the next call as well. Adam will chime in.

[Kim Cameron]

Thanks for the comments and attention to the role of PWAs in our evolving architecture. Sorry my response is long, but I want to drill into the issues raised by the comments.

Tom Jones says, “It needs to be pointed out that the relying party has no access the code actually run by the user agent and so cannot get any level of assurance from it.”

Tom, it is true the relying party cannot “access the code actually run” by a given instance of a user agent, just as the RP cannot “access the code actually run” by any OP with which it is not co-located.  Yet in spite of not “accessing the code actually run”, RPs routinely draw conclusions about the level of assurance OPs provide.

The conventional OP’s hosting environment appears to be a straightforward one in which code runs on servers controlled by the OP and should therefore be identical for every transaction.  Yet experience shows that because code is dynamic and requires the propagation of fixes and enhancements at various levels of the stack, and because code deployment systems and processes are imperfect, defective code can indeed be deployed to some or – at the limit – all server instances, causing service outages.

Because of this danger, “staged deployment” has become the norm in large production systems so that upgrades (which always have the potential of causing bugs) can be “validated” on real customers and rolled back before impacting the mass of the customer base. This in fact means different transactions are actually using different versions of the code.  My point here is simply to underline that RPs routinely “get levels of assurance” based not on a proof about the specific code being run in a particular transaction, but rather based on the provider’s operational procedures, reputation and audits.

In the case of PWA-based user agents, a combination of the components in the technology stack and the reputation of the PWA provider allow RPs to draw similar conclusions about levels of assurance.

1. When the RP requests a token from the PWA, the browser guarantees that it can only do so using https.  Therefore, as explained here, assuming the RP has taken steps to safeguard its own DNS infrastructure, it can be certain that it has redirected to the endpoint of the PWA on the user’s device. 
2. The service-worker and other OS/browser components instantiating the PWA on that device verify the integrity of the code being run and its origination from the PWA’s web service. 
3. A properly written PWA user agent will therefore be able to reliably convey its software version number and assurance guarantees in the token it returns to the RP.  
4. Clearly if the user’s device is “owned” by an evil party and its operating system and stack sufficiently compromised, some or all of these guarantees will be undermined.  Yet this is the case for any software running on a device, and applies equally to a system running a native (non-PWA) user agent or even interacting with a remote user agent via web or other protocols. Therefore let’s factor such attacks out of the PWA discussion.
5. PWAs storing keys locally may not be able to claim they are stored in a protected hardware enclave.  On the other hand, PWAs can operate in conjunction with remote key stores based on protected hardware enclaves, and still be able to offer such guarantees.  To be sure, the use cases for which a given PWA is applicable may be different depending its approach to key storage reflected in the level of assurance claimed as conveyed in the issued token.

Tom, I would like to learn more (at a high level) about the regulations you are referring to.  I have personally been able to download my entire (vast) medical history from my Seattle hospital using simple browser / email technology without any of the protections discussed here except use of https… Not only were there no hardware keys used at the client end, there were no non-extractable asymmetric keys.

---

Having looked at the flows, James Manger writes, “Presumably the PWA asks the user's browser to generate a key-pair; hopefully hardware-backed; perhaps requiring the user's device-unlock gesture for each operation with the private key; and maybe with an attestation (chaining back to the O/S vendor and/or device vendor) that the key has these protections. The PWA will use the private key to sign SIOP responses.”

I think the high order bit is this:  The fact that a user agent is a PWA doesn’t determine how the PWA stores its keys or the highest level of assurance that can be achieved.  In my response to Tom I pointed out that a PWA can store keys locally or work in tandem with a remote key storage system offering all the hardware guarantees you cite.

But to pop up a level, in my view it would be wrong for us to decree that all user agents must have all the capabilities you list.  

I think it’s important to start from the current state of the web and the level of security it delivers, and compare that to the capabilities offered by even a simple PWA, including the use of integrity checked code, and asymmetric non-exportable keys.  We are talking here about a very significant upgrade, and there are innumerable use cases that would benefit immediately from such an upgrade.

There are indeed other use cases where enterprises and governments would want stronger assurances, so use of a native user agent or of a PWA with a remote key store would be warranted, in spite of introducing some friction in the user experience.

To me it makes sense that a wallet provider adopt a ‘pay as you go’ attitude to the friction/security payoff.  We have encountered important scenarios where the goal is to achieve very wide adoption of credentials very quickly for use cases where the difficulty of attack far exceeds the possible benefit of doing so in a decentralized system.

The other important thing is that any SIOP user agent report its capabilities, regardless of what they are, in a believable and auditable way.  As I tried to explain in my response to Tom, PWAs make this possible.

James continues, “An RP doesn't get any assurance that a user is running the true itsyourweb.org wallet. The user could have installed their own root CA and their own DNS settings pointing itsyourweb.org to their own site. But, under the assumption that a user is running a "normal" browser on a "normal" O/S, the RP can assume the itsyourweb.org wallet is running, with all the protections and consent screens that itsyourweb.org is trusted to implement. That may be sufficient for an RP to show a duty-of-care towards users by only supporting quality wallets”.

Actually, a user who installs his own CA and DNS and impersonates a Wallet linked to a public URL is only able to attack himself… To deceive an RP he must allow it to connect with him. When the RP (with a valid DNS system) attempts to make this https connection, it will detect the fake certificate of the fake PWA.  If the attacker has restored normal DNS to his lab environment and left the fake wallet in place on his machine, the code will not be recognized as valid when it attempts to start up and connects with the real PWA service.

James says, “A user with such a wallet can only use it at RP that explicitly supports this specific wallet vendor; ie an RP that lists itsyourweb.org alongside, say, Facebook & Google as supported OPs in a NASCAR-style list of logos. In the example, Air Canada (the RP) shows a QR code specific to itsyourweb.org (not any other SIOP).”

This would be true if the discovery problem is not solved, but we have proposals for that, so let’s factor it out of this discussion.  When a generalized SIOP discovery mechanism is available, the RP can have a single Decentralized Identity on its NASCAR list - or, better still, move beyond that whole NASCAR concept once a user has a wallet in place.  The discovery mechanism can include ways to specify wallets accepted by the trust framework behind a verifiable credential.

‌

[Tom Jones]

I would like to take issue with Kim’s statement “this is the case for any software running on a device, and applies equally to a system running a native (non-PWA) user agent or even interacting with a remote user agent via web or other protocols. Therefore let’s factor such attacks out of the PWA discussion.“

There are several reasons why the value of certification of native apps needs to be taken as more secure than PWAs. I will assume that the the O/S is from apple or android and so has the cache' that they have earned over years of reasonable secure use. The apps of interest today come from app stores which also provide some level of identity if not security. That may change in the future.

Certification of apps is envisioned in the SSI community, altho not yet defined. Certification of apps in the First.net community is already well developed and seems to be working well. The following generalized certification proposal has been published as an implementer’s draft and is intended to provide a certification for apps that handle user protected data. I will try to address the regulations about Health data elsewhere. https://kantarainitiative.org/download/kantara-mobile-assurance-statement/

While it would be nice to think that vendor signed code was sufficient, I believe the “Solar Winds” breach puts that in serious doubt.

[Kim Cameron]

Hi Tom,

The wiring for the PWA, and all the security checks it provides, is provided by Android and Apple as part of its OS and browser technology. Both players have invested heavily in their PWA technology. PWAs on these platforms are not some fly-by-night technology unworthy of use and indeed represent a huge step up from current web security. I think we should take advantage of these new technologies.

BTW - the PWA code is NOT signed by the vendor - it is protected by the PWA infrastructure delivered by Apple and Android.

Thanks for the link I will follow up.

‌

[Tom Jones]

Kim: I agree with all you say. That does not change the trust that is in the PWA. That is entirely from the download URL. For example solarwinds is perfectly capable of providing a PWA com.solarwinds.you_can_trust_me

[Kim Cameron]

I also agree 100% that the PWA service can supply evil or incompetent code. So without any reputation PWAs are, like all software, “user beware”.

But let’s imagine the pwa at https://great_wallet.com provides a great wallet. .Experts can download it and even examine the source code and rate it. Users and RPs can evaluate its usability and reliability. People who use the wallet can be certain - because of the pwa infrastructure - that the wallet is running code actually issued by great_wallet.com, not some attacker. If the wallet claims certain capabilities in its token, relying parties can be certain that https://great_wallet.com - which by now has a reputation to stand by - claims those capabilities, not some attacker.

Most important, a trust framework built around verifiable credentials can put https://great_wallet.com on its list of approved wallets so that automated validation software can accept the credential.

Thanks for helping me make progress in explaining the potential I see in PWAs - I now understand much better the things we will have to explain in conveying how the technology addresses our problems - sorry if it’s taken a while to bring out all the salient elements. - there aren’t many people to talk with at this level of focus, detail and clarity.

‌

[Tom Jones]

I admit that i am focused on certified apps with a signed checksum and all that.

But others have focused on certified devs. I have not explored that path myself.

I believe it would be possible to create some sort of certification that could apply to either devs or to apps. That might be worth some energy to explore further.

[Michael Jones]

It’s not clear to me what needs to happen in the spec for PWAs to work. Maybe a PR would help clarify this.

[Kristina Yasuda]

Dmitri said that the main obstacle in SIOP v1 for PWA is the usage of custom URL schema for invocation, because of the poor support of it by the browsers. John suggested filing that use-case with Federated Identity WG in W3C to get attention of the browsers.

Reference: what Google is proposing for Identity mediated by the browser: https://wicg.github.io/WebID/

[Kristina Yasuda]

resolving this issue for now based on the feedback from Adam that SIOP v2 as-is works with PWAs. (cc @Torsten Lodderstedt )