Re: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse retriable

[Mark Little <mark.little@jboss.com>]

+1

Alastair Green wrote:

> Kevin,
>
> In my mind the trust issue is a separate concern.
>
> The same applies to the transaction (context identifier), does it not? 
> That is a URI in the clear.
>
> Why would we trust the uniqueness of message ids, (which are not 
> generated by the processor incidentally)?
>
> It's very difficult to stop a trusted counterpart from abusing your 
> trust. You know it's them; you know the message is unaltered, you know 
> it's well-formed, you know it's legal vis-a-vis the spec, but it's 
> actually a load of rubbish. Either it's a bad implementation, or they 
> are trying to attack you. Ultimately, the only sanction on that is to 
> stop trusting.
>
> Alastair
>
>
> Kevin Conner wrote:
>
>> Alastair Green wrote:
>>
>>> I agree, and I believe that a URI or IRI has the useful property of 
>>> being a globally unique identifier. This seems like a non-problem. 
>>> Cf. Use of URI for /CoordinationContext/Identifier.
>>
>>
>> It certainly has the potential for being globally unique, at least 
>> with a certain degree of confidence, but the issue is still one of 
>> trust that the third party is generating unique identifiers.
>>
>> The current specification does not require the registration or 
>> protocol services to trust any other identifier than the one it 
>> generates. The identifier is scoped to its service(s).
>>
>> The suggestion to reuse the register message implies that collisions 
>> in this identifier space cannot happen, especially if the register 
>> response cannot return a failure message and must blindly accept the 
>> contents of the EPR.
>>
>> If we go down this route, which does seem appealing to me, then I 
>> believe we should assume that collisions will be possible and work 
>> defensively.  A valid response to the register request should be that 
>> the identifier is already used (it may be a collision) and that a 
>> recovering participant/AS should be required to identify itself using 
>> a different request message.
>>
>>     Kev
>>
>>
>