Re: Open Wallet Foundation (and how it might fail)

Hi Anil,

> Am 23.09.2022 um 02:54 schrieb John, Anil <anil.john@hq.dhs.gov>:
> 
> Hi Torsten,
>  
> >The sub table „Credential Formats“ at line 15 has a columns for the standards body and the respective specification. 
> >Regarding protocols: I’m aware of work under way at w3c, OpenID Foundation, DIF, and ISO.
>  
> Your forgot Hyperledger,

because of DIDComm/Present Proof Protocol and so on? I thought that has moved to DIF. 

> Trust-over-IP,

What protocols does ToIP define? As far as I know ToIP is technology agnostic. 

> the Ethereum Foundation and a host of others …

for the payment part? I’m just to identified biased ;-) 

>  
> I am aware and each time I see this, I am reminded that irrelevance is built on a foundation of infighting and that empires only fear barbarians who can think beyond their tribes.
>  
> >A clear articulation of what features/capabilities should be within a core, normative, baseline of a digital wallet
> >that is expected to store and manage high value credentials, and what should be optional / value add
> >>>That’s a good question. Do you have a proposal?
>  
> Not yet. 
>  
> We have been having this discussion internally and even with the people ‘in the room’ who are thoughtful, competent, implement/ship products and are vested in reaching agreements, it has been a lengthy and sometimes frustrating set of discussions – and that is with people who actually respect and like each other IRL! I think we are at a stage where we actually have agreement on a common set of facts, instead of positioning/posturing.
>  
> When that is refined to something that is usable, semi-testable and can meet our needs, we intend to share it and see how it lands with the community.
>  
> >How those features can be detected by issuers and verifiers
> >> To me that sounds more like a regulatory framework than a technical standard. The upcoming eIDAS 2 regulation, as one example, will cover those aspects.
>  
> If you don’t want to go down the path of product detection, you need feature/capability detection and the longer folks put it off, the easier the product detection path will look to folks who don’t want to think about or don’t want to care about its long term implications.
>  
> >>How wallets can signal intent and capability to an Issuer and Verifier such that they can make a risk-based decision to interact with that wallet
> >>I would like to better understand what you mean. Is this about metadata (capabilties) or risk signals?
>  
> Wallet to Issuer
> I support FIPS compliant cryptography
> I support storage of data in a hardware element

That seems reasonable but do you assume it would be sufficient to just signal FPIS compliance? As an issuer I would like to know (in the sense of trust this claim). I therefore think this requires some kind of trusted 3rd party attestation either of the technical capabilities or by a conformance assessment body. 

> I can dance under the pale moonlight but not in sunlight
>  
> Wallet to Verifier
> I support selective disclosure capability Y

> I support credential aggregation capabilities
> And so on …

+1

Defining such signals is feasible. However, I think it requires OS or Web Browser support to actually conduct this negotiation. The alternative is to define conformance profiles and bundle capabilities and invocation, e.g. through custom scheme. If the verifier, for example, uses custom scheme „euid_wallet“ it knows the recipient on the other end shall be compatible to the eIDAS ARF. 
In case of cross device it is typically the user who selects the wallet it scans the QR code (or establishes the near field connection) with. I guess she also needs to understand what wallet to use. 

best regards,
Torsten.   

>  
> Best Regards,
>  
> Anil