Re: [W3C Web Crypto WG] Rechartering discussion - Gemalto contribution

Ryan -- if we are able to collaborate and come up with a web implementation
architecture that not only encompassed FIDO, but also equally viable
standards such as PIV Derived Credentials [1] and EMV Tokenization
[2]....and such standards to come in other industries, will you be
supportive of it. Or, you do not want to support anything other than FIDO?

Same question for Anders and Brad.

Best,
Siva

[1] http://www.nist.gov/manuscript-publication-search.cfm?pub_id=914530
[2] http://www.emvco.com/specifications.aspx?id=263


*--*


*Siva G. Narendra Ph.D. CEO - Tyfone, Inc.Portland | Bangalore |
Taipeiwww.tyfone.com <http://www.tyfone.com>*
*Voice: +1.661.412.2233 <%2B1.661.412.2233>*


On Mon, Feb 2, 2015 at 1:44 PM, Ryan Sleevi <sleevi@google.com> wrote:

>
>
> On Mon, Feb 2, 2015 at 1:35 PM, Harry Halpin <hhalpin@w3.org> wrote:
>
>>
>> For non-W3C members in FIDO (NokNok come to mind) and in GP, we have
>> processes and legally binding agreements to get the proper patent
>> commits from 3rd-party members.
>
>
> Harry,
>
> I fear you have misunderstood the problem. *NO* such agreement is needed
> for FIDO, whereas no such agreement can be *made* with GP precisely because
> members are allowed to hold onto patents crucial to GP without licensing
> them.
>
> So unless/until you can get every GP member to join such a hypothetical WG
> (which again, I do not believe should be WebCrypto), then it would be
> knowingly standardizing an encumbered technology. Surely you and your
> colleagues at the W3C can see the fundamental danger in this.
>
>
>> So again, the only block from a patent
>> perspective is if a non-W3C member in either FIDO or GP didn't join W3C
>> or fill out the necessary paperwork. We can even start that paperwork
>> process *now* (as lawyers tend to take a while) by sending both the
>> relevant parts of FIDO and this new Gemalto submission through the W3C
>> member submission process.
>>
>
> To be abundantly clear: I consider the Gemalto solution as unimplementable
> as is, *independent* of the GP issues. But the fact that there ARE GP
> issues, and not disclosed, is equally troubling.
>
>
>>
>> I'm not sure how useful a CG is if FIDO and Gemalto already have more
>> mature-ish proposals.
>
>
> It would be mistake to call the Gemalto solution mature when compared with
> FIDO. It is architecturally similar in flaws to the PayGate proposals of
> the past.
>
>
>> The problem is to see how these use-cases can work
>> together in a way that respects the privacy and security features of the
>> Web Security Model while also allowing access to user-controlled
>> hardware tokens that have not been part of the Web yet.  If that wasn't
>> the case, yes, then a CG would make perfect sense.
>>
>
> To be explicit; I disagree with the premise that it is a good or
> worthwhile goal to expose these tokens. That sets an unquestionably wrong
> set of priorities - that is, it assumes we must, and thus we will shove any
> solution that fits "close enough" into there. The question is not "How do
> we", it is "How could we" - a question that recognizes that the answer may
> be "We can't", or that more changes are needed than just at the W3C level.
>
>
>>
>> Regardless, I think we should assume all parties are operating in good
>> faith as regards IPR and be aware that W3C has strict, and even tedious
>> processes here, but we can make it work. I'd like to see the discussion
>> focus on Brad's points a bit more but try to aim at the Gemalto proposal
>> in a constructive manner rather than say 'throw proposal away' - as we
>> do not have any alternative proposals actually on table formally yet.
>>
>>   cheers,
>>      harry
>>
>
> This is a fundamentally flawed process. The proposal put forth ignores
> much of the conversation had for _years_ during our past meetings and on
> the list, and yet is proposed as new and novel. It's not. There are enough
> fundamental, architectural issues that it really is incumbant upon the
> proposers to re-evaluate the approach, rather than suggest that unless
> members assiduously and meticulously tear apart *and rebuild* the
> solution, that it's somehow the best.
>
> No, we have at least one concrete proposal that is far more mature with
> respect to privacy - FIDO - and the security considerations should serve as
> a baseline for any counter-proposals. A proposal that actively ignores or
> attempts to dismiss these considerations absolutely deserves to be on the
> pile of "throw proposal away."
>
>