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

It is necessary for us to keep things in perspective -- when we are taking
about encumbered due to IPR, let us keep in mind that IPR of NPEs (aka
Trolls) far out weigh member companies that are practicing entities. NPE
market in 2011 was $29bn [1]. No organization can protect against action of
NPEs and non-members.

IPR is not an issue that this proposed WG/IG is qualified to resolve or
guarantee. So, let us focus on what would it take to make the web more
generic (including FIDO) rather than restrict it only to FIDO.

[1]
http://www.bu.edu/law/faculty/scholarship/workingpapers/documents/BessenJ_MeurerM062512rev062812.pdf




*--*


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


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

>
>
> On Mon, Feb 2, 2015 at 1:10 PM, Harry Halpin <hhalpin@w3.org> wrote:
>
>>
>>
>> On 02/02/2015 10:00 PM, Siva Narendra wrote:
>> > Hi Ryan  --- IPR related to GP is dangerous compared to what? FIDO is
>> not
>> > immune to IPR -- is it?
>> >
>> > At least in the case of GP it is mature to enough to know who owns what.
>> > According to this document attached (and available online here
>> > <
>> http://fidoalliance.org/assets/downloads/FIDO_IPR_-_Counsel_Approved.pdf
>> >)
>> > it is clear that FIDO is concerned about IPR just as much as any other
>> > standards would be.
>> >
>> > Irrespective, it is precisely this unknown that would make it more
>> > dangerous to limit the web to one protocol with unproven IPR that might
>> > ultimately stifle innovation.
>>
>> Note that as regards both FIDO and GP, W3C Rec-track standardization is
>> a good thing from an IPR perspective and we should not let IPR concerns
>> block the right set of specs being produced.
>>
>
> Harry,
>
> My point is not to block, but to merely show that a GP-based system is
> *known* to be explicitly less-friendly towards standardization.
>
> That is, GP holders can (and do, as noted by that page) hold crucial
> patents for GP and are allowed to assert those, whereas FIDO Alliance
> members expressly grant license to implement FIDO specs.
>
>
>> The reason a *Working Group* is useful is due to the stronger patent
>> commits to the charter and final specs once they hit W3C Recommendation
>> status, as relevant patents are bound to be committed by member
>> companies and invited experts to the final document under a royalty-free
>> licesning. If not, we have a mature patent exclusion and patent advisory
>> group process I'm sure Wendy and Rigo can describe in detail if needed.
>> It would be problematic to bind to IPR in any normative way, which is
>> one reason the W3C is rather strict with its normative referencing
>> policy - as painful as that makes creating the specs sometimes.
>
>
>> A Community Groups offer a much weaker form of IPR protection, which is
>> one reason why a Working Group would be preferred in this space.  As one
>> of the initiators of the Community Group process inside W3C a few years
>> back, I can explain in detail if needed, but effectively it requires
>> only individual level IPR commits, not company wide.
>>
>
> And given such exploratory, unbounded efforts, which so far have crucially
> misunderstood or maligned core web security features, it would be far
> useful for a CG to form and explore the space, and then bring forward to WG
> and reveal whatever IPR issues may exist IF and ONLY IF such a proposal can
> sensibly address security.
>
> However, it's far more important to keep it simple - GP is a
> known-encumbered technology. A proposal that says "We can use GP" is thus
> knowingly encouraging encumbered technology, whose members are not part of
> the WG and may not be bound. FIDO MAY be encumbered, but to the extent that
> it is members of FIDO Alliance, a W3C acceptable RF grant has already been
> made. So the only risk is of external parties, and that risk exists for
> _any_ W3C spec. Unlike GP, which is clearly restricted.
>