search

e-clearing-net / OCHP

Open Clearing House Protocol
http://ochp.eu
MIT License
47 stars 33 forks source link

Clearer use of 'identification token' definition #6

Closed simplerun closed 8 years ago

simplerun commented 8 years ago

Definition of identification token was misapplied resulting in ambiguous conclusions.

  1. Not "identification tokens" - plural, only one identification token in one request.
  2. Identification token is not distributed via the CH. Only partners tokens get distributed.
  3. Definition of identification token must be first sentence after usage of the 'identification token' notion.
mtdern commented 8 years ago

IMO it is important to keep the distinction between singular tokens (i.e. the tokens that get uploaded to the CH along with the endpoint information) and the token combinations that get used for authorization at the OCHPdirect endpoints. Your edits might introduce confusion here...

simplerun commented 8 years ago

Hi! You are right, I'm introducing more unnecessary confusion into the subject. Sorry about that. I will try to be precise. My confusion started with sentence "The identification of the requester and ... " and to the end of the section. After repeated reading I think that I'm in sync with Your intention when You wrote that description. But, my opinion is that after one reading I should have clear and complete picture of this authentication and authorization procedure. From my point of view it is important to have clear separation between notions of : partner identification token, concatenated tokens pair, authorization string value. Combined vs concatenated word, small difference, I lean toward 'concatenated'.

Please look at this alternative version, as an suggestion : Roaming partners distribute their identification tokens via the clearing house on daily basis. On receiver side the identification of the message sender is done by use of identification token from sender downloaded earlier. Sender identification token is part of a constructed authorization string value in authorization HTTP header when sending a message.

Each request/response to a OCHP direct interface must contain a Authorization HTTP header:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

The hash value (i.e. authorisation string value) in this header is constructed through the following steps:

  1. The identification tokens of sender and receiver are combined into a concatenated tokens pair string "receiver-token:sender-token" with colon as delimiter.
  2. The resulting string is then encoded using the RFC2045-MIME variant of Base64 (RFC1945)
  3. The authorization method and a space i.e. Basic␣ is then put before the encoded string.

The OCHP direct endpoint should check for valid authorisation in order to prevent unintended usage of their endpoints or cyber-attacks.

... Change use of "token combinations" to "concatenated tokens pairs".

I'm not fluent in English, my apology for all language mistakes.

mtdern commented 8 years ago

We will make some changes to the documentation asap (working on OCHP and OCHPdirect at the moment anyway and will include this) to hopefully clear this up. Thanks for the input!