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

The DOMCrypt signature method does not have many similarities to the schemes
used by banks and for authentication they already have TLS-client-cert-auth
as well as proprietary replacements for that.

Most important: banks use certificates; not plain keys.  Certificate selection
is done by "trusted GUI" and not by arbitrary keyID parameters.

Calling cryptographic APIs from *untrusted browser code* is actually a rather
"narrow" use-case.  That makes it a good candidate for standardization though :-)

Planning to extend DOMCrypt in some distant future to also support the
bank use-case is (of course) OK, but I wouldn't hold my breath on that one.

There may even be some healthy competition in this space :-)

To summarize: preferably drop all references to the bank use-case.

Anders



On 2011-12-09 13:50, Harry Halpin wrote:
> 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 13:42:04 UTC