- From: Anders Rundgren <anders.rundgren@telia.com>
- Date: Tue, 09 Jul 2013 22:45:52 +0200
- To: Mark Watson <watsonm@netflix.com>
- CC: "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>, Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
Mark, http://lists.w3.org/Archives/Public/public-webcrypto/2013Jul/0061.html "For the moment, the only use-case we have is when the pre-provisioned keys are associated with the device. So there can be no ambiguity - the application knows exactly the names it is looking for and there is only one key for each name. We should keep the API simple until we have a concrete use-case motivating more complexity" I don't think there's a need to investigate more use-cases. The current obstacle (as I see it NB...) is rather that Netflix's variant of pre-provisioned keys have obtained "carte-blanche" in the Web Crypto WG while other forms of fairly wide-spread pre-provisioned keys have been "outlawed". IMO, the X.509-based SOP emulation scheme that has been described in the comment-list is no worse than the original Web Crypto concept because it doesn't matter much what kind of solutions identity providers uses; if they want to screw their clients they can usually do that. Regarding the draft itself: The steps Key Enumeration + Key Attribute Retrieval + Optional User Selection is an established way of selecting keys for cryptographic operations and should work for any use-case. There would be a minor overhead for your specific use-case but that's typically the price for generality :-) Anders
Received on Tuesday, 9 July 2013 20:46:25 UTC