[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse retriable
+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 >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]