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

On 02/02/2015 10:44 PM, Ryan Sleevi 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.

I believe an agreement would be needed if any member of FIDO contributed
to the API and was not a W3C member. The same would go for GP. It does
appear FIDO is more in-line with W3C than GP in terms of licensing, but
we'd still need re-commits from FIDO.


> 
> 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.

Again, we'd need commits from GP and can get commits from non-W3C
members via the process and paperwork I outlined earlier without them
joining the WG.

Regardless, I'd like to keep the patent discussion off the table, as we
can fix it for any and all proposals if parties operate in good faith,
and focus on technical details at this relatively early stage.

However, we will be sending some of you off-list patent related emails
and paperwork once a proposal is ready for "W3C Member Submission" which
is where both Web-facing FIDO APIs and the Gemalto proposal should
likely end up sooner rather than later.

   cheers,
      harry

[1] http://www.w3.org/2014/Process-20140801/#Submission

> 
> 
>> 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."
>

Received on Monday, 2 February 2015 22:07:32 UTC