Re: Registries and Interoperability

On 02/07/2013 03:25 PM, GALINDO Virginie wrote:
> Dear all,
> Maybe being a bit classic-style in standardization, I would recommend the W3C maintains a consistent set of specification and test.
Virginie,

Don't confuse a normative specification (the "live spec" idea, with is 
orthogonal to this discussion) with a registry for listing non-normative 
algorithm identifiers and/or security considerations.

In fact, the reason the W3C suggested a registry upon internal review 
was precisely the point that the charter does end, so there's not a 
"live spec".

>
> In your proposal Harry, you mention that new algo added to IANA will only be included if test case are provided, but if you start requiring X implementations, then I think that you are closed to have enough people to re-open a WG.

Again, we could also use an alternative regime as Richard suggested and 
just have "Well Specified". It's up to the WG to figure out a sensible 
policy. I was suggesting that Ryan's proposed "sensible policy" could be 
handled by a registry if needed.

> I perfectly understand the drawback about the W3C process to re-open a WG (6 months to set up the group, minimum 4 months to amend the Recommendation...), but on the other hand, the delegation to IANA of W3C spec maintenance may lead to a situation where maintenance is not made, because involving complex new process, which is not W3C *members* visible.
No, the process I suggested generally would involve handing off after 
the lifetime of a WG the following two items:

1) maintaining security considerations per identifier to the CFRG, which 
operate on a public list
2) maintaining requests for a new algorithm identifiers in a public 
registry, with requests on a public list and the test-cases being 
publican accessible.

Some may consider this sensible as the crypto landscape does change and 
will thus likely change after the lifespan of this WG.

>
> I am not trying to maintain my chair seat for my entire life, I am more suggesting that the Web Crypto WG deliverables are maintained by the same process and in the same policy as when being created. If this requires to re-open a WG, we should do that.

In general, one should not assume one is going to "re-open" a WG. One 
should also assume Web app developers may read the spec for quite a 
while - perhaps years  - after the WG closes.
>
> Now if the W3C direction is so clear that they want the spec to be lively without a WG, then I would suggest we start working on a document describing the exact process if we go with IANA collaboration, and the exact IPR implication it may have.
>
> Regards,
> Virginie
>
> -----Original Message-----
> From: Harry Halpin [mailto:hhalpin@w3.org]
> Sent: mercredi 6 février 2013 10:57
> To: Ryan Sleevi
> Cc: public-webcrypto@w3.org
> Subject: Re: Registries and Interoperability
>
> On 02/04/2013 10:55 PM, Ryan Sleevi wrote:
>> On Mon, Feb 4, 2013 at 1:22 PM, Harry Halpin <hhalpin@w3.org> wrote:
>>> Quick note,
>>>
>>> I agree with Ryan's concerns as regards registries not allowing
>>> interoperability and possibly being dangerous from an IRP perspective.
>>> However, from W3C's perspective we we're not planning on running the
>>> Working Group in an open-ended manner like the WebApps Working Group
>>> (see below for reasoning). Thus, it seems we should determine:
>>>
>>> 1) If we want any extensibility in algorithm identifiers, which
>>> requires either a very low-bar approach (wiki) or a high-bar approach
>>> (IANA)
>>> 2) If we don't want any extensibility in algorithm identifiers, so
>>> they essentially "freeze" when we go to Last Call, and adding new
>>> ones requires rechartering the Working Group
>>>
>>> I think there's the situation where there's a new algorithm people
>>> may want to use, but we don't have enough industry momentum to reopen
>>> the Working Group.
>> If there's not industry momentum and within implementors, what value
>> does it serve the broader web community of users, authors, and
>> developers? If there is broad consensus, then what's the challenge?
> There may be momentum to add a new algorithm or tweak an existing algorithm from within two or more implementers without the momentum needed to re-charter a new Working Group. Or if the registry includes security considerations, there may be an update to security considerations We would not want to recharter internally at W3C for a new single algorithm or a change in the security status of an algorithm, as we would have to identify editors, chairs, and go through IPR process all over again.
>
> Again, from W3C processs point of view, we just need to determine 1) when working group ends and 2) if it ends, is a maintenance policy necessary and 3) is there a clear well-specified way to maintain, and can that be done outside the spec for minor changes via a principled extensibility point?
>
> It seems given the crypto landscape does change on occasion, a maintenance policy makes sense. IANA was suggested by W3C internally as a principled extensibility point, as we have a long history of working with them. I'm open to other suggestions. Do people agree that no maintenance policy on algorithm specifiers are necessary?
>
> In fact, we could even broaden the scope and also allow the registry to, in conjunction with the work CRFG is doing already, make sure that algorithm's particular security considerations can be updated and noted on a per identifier basis. This deals with the "ever-changing" world of crypto, as you put it earlier. I do think crypto actually changes quite slowly, but sometimes there are dramatic new changes that happen very fast. This would address CRFG's comments I believe re the use of "broken crypto" in the spec.
>
> I am bringing this up a bit early insofar as that it can take some time to go through getting a new IANA regsitry, and I don't want that holding up Last Call.
>>> As I understand it (and Wendy's a lawyer, so she can correct re IPR),
>>> the real advantage of process is testing and IPR RF commitments.
>>>
>>>   From a W3C Process point, the IPR is assigned at the Recommendation
>>> phase, with initial commitments made to charter. The advantage is
>>> that features of the W3C Rec for Web Cryptography will have a high
>>> assurance of royalty-free implementation, regardless of the test-cases.
>> We should be clear here: royalty-free with respect to participants.
>> There's always the possibility of external factors here, which is part
>> of why having the WG process works, to identify and find solutions to
>> these factors.
>>
>>> The disadvantage of that is to
>>> add a new algorithm via adding a new identifier, we'd have to re-open
>>> the Working Group and start the IPR process all over again.  However,
>>> any registry would not have W3C RFF IPR policy, although we could
>>> apply an IETF policy to it (which I would strongly suggest).
>>>
>>>   From a testing standpoint, another strong point is that W3C requires
>>> demonstrated interoperability. However, *running* the test suite and
>>> adding new tests does not require re-opening the Working Group,
>>> unlike making modifications to the specification. The test-suite can
>>> be stored using Git in order to allow merges, and will be maintained
>>> by W3C after the lifetime of the Working Group. We can add our
>>> test-suite to be part of a larger test-suite (I would think HTML WG's
>>> test suite would make sense) so it can be easily added to by others
>>> and maintained after the lifetime of the Working Group.
>>>
>>> My suggestion for a process is then:
>>>
>>> 1) Keep algorithm identifiers in the specification up until we go to
>>> Last Call, and that the test-cases for Rec status test each of them.
>>> Thus, no text is removed from spec. We clearly specify that
>>> algorithms in the spec have RFF status, demonstrated interoperability
>>> (via test-suite), and are to be preferred by WebApp developers.
>>>
>>> 2) Then after that period, people proposing new algorithms are asked
>>> to go to the IANA registry, which will have some explanatory text
>>> referenced in the spec.
>> As mentioned, this remains a troubling proposal.
> In what regard in detail?
>
> The alternative seems to be:
>
> 1) We keep the WG running forever to maintain the spec (which is difficult)
> 2) We recharter whenever even minor changes to algorithm identifiers or security considerations are needed (again, very difficult to recharter - the process itself just to start takes about 6 months at least usually due to IPR considerations).
>
> I think that address the interop concerns, and also gives us a clear process for when we need to reopen the Working Group. We can set some specific criteria to formally suggest to the W3C to re-open, such as when we have say, X implementers for more than X algorithms. At the same point, we get to have a place where new identifiers  can go.
>
>>> 3) The IANA registry have a fairly stringent requirement of at least
>>> two interoperable user-agents as well as the "Well-Specified" text
>>> given by Ryan in the spec already in order to get in registry.
>> As I mentioned, this text was certainly not intended to be a long-term
>> text. I would propose this be removed, as it was more of an editorial
>> note (before I discovered the "ednote" attribute of the tools)
>>
>> I think it's demonstrably harmful to the spec and the process to
>> include this text going forward.
>
> Note that "this text" was the text in you added to the specification about a registry, to be clear.  That's what caused the internal discussion at W3C in our review at our last "heartbeat" publication.
> Again, can you explain why its demonstrably harmful and what a clear alternative is?
>
> I have suggested a wiki as well (which is what HTML/WHAT WG does re link
> registry) but that's even more likely to be messy than an IANA registry with a well-defined policy.
>>> 4) The W3C/IANA contact for the registry check new requests for
>>> algorithm identifiers by demanding test-cases. These can get added to
>>> an "experimental" branch of the HTML test-suite.
>>>
>>> 5) If we get to the point where we have lots of new algorithms and
>>> momentum is clear, the contact recommends re-opening/re-chartering
>>> the Working Group to the W3C. The W3C/IANA can reject spurious new
>>> identifiers (including ones that make only minor modifications to
>>> those in spec) or one's that are known to have IPR issues.
>>>
>>> Ryan, does that address the your concerns?
>> No
> OK. What's your alternative?
>>> Any thoughts?
>>>
>>> The W3C and IANA have a fairly close relationship, and we are used to
>>> dealing with IANA in this way in other WGs, so the mechanics aren't
>>> an issue. We just need to figure out what's best for the WG - to have
>>> an extensibility point or not, and if so, what are the requirements
>>> that we at W3C (and any volunteers!) can maintain after the lifetime
>>> of the WG. We do prefer to close WGs as it helps get us the IPR
>>> closed, and in general increases the chances of interoperability by
>>> demanding implementation by a given date.
>>>
>>>      cheers,
>>>        harry
>>>
>>>
>>>
>>>
>>>
>>>
>

Received on Thursday, 7 February 2013 17:28:01 UTC