Issue on certificates, choice, and enrollment - the "Korean banking" case

I'd like to tackle this use-case, but want to prioritize getting the 
basics right (ala DomCrypt as it stands right now) before extending the 
API to include the features necessary to handle the banking use-case. 
Thus all features around this use-case are in the "secondary features" 
section. This means that they have to carefully explained and justified 
in the use-case document before going into the core API.

We're heard lots of vastly differing stories about the details of the 
"korean banking use-case." The most complex involved smart-cards and UX 
specification. It seems in the simple case what is really needed is to 
simply sign a certificate with some interaction of the user with a 
prompt ala this possible addition to DomCrypt [1].

So signing some digital object (i.e. a certificate) is in primary scope 
as "digital signature generation and verification) and more complex 
lifecycle management  - "lifecycle control of credentials (such as the 
enrollment, selection, and revocation of credentials)" is in secondary 
scope [2]. Also note that we will not normatively mandate any UX in a 
standard, but will have to suggest that the user interacts, thus this 
new section has been added:

"Note that the details of any user experience (such as prompts) will not 
be normatively specified, although they may be informatively specified 
for certain function calls." [2]

Any objections? Does this work for this use-case for folks?

    cheers,
        harry

[1]https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest#Possible_Additions
[2]http://www.w3.org/2011/11/webcryptography-charter.html

Received on Friday, 9 December 2011 12:50:44 UTC