[Nsi-wg] Addressing connections across requesters

[Henrik Thostrup Jensen]

Hi

I was trying do add authorization support to OpenNSA, but came up short on 
a lot of rather simple things involving third party. I've raised some of 
these issues before, but we never really get around to doing actually 
solving them.

Description of the problem:

Currently the connection id is specified by the requester, meaning that is 
has to be scoped within the requester identity, as there is no way to 
ensure that client chooses a unique one (no UUIDs does not solve this 
problem as it only covers accidental clashes, not malicious).

This means that if A creates a connection at B. There is no way for a 
third party (C), to address the connection at B. I think this is a 
problem.

Global ID is currently optional, and is specified by the client, so it 
cannot be used for anything in this.


Possible solutions:

A: Letting connection id to be scoped within the provider.

This means rejecting requests which has an already specified connection 
id. This is fairly straighforward and simple, and is unlikely to cause 
havoc in the real world.

B: Letting the provider choose the connection id

The connection id would then have to be returned in the response. This is 
very simple, but somewhat opposite of what we have done so far. This has 
problems with crashes/message loss (the requester does not know the 
connection id until it gets the reply). This can be worked around though.

C: Including the requesterNSA in the connection.

The essentially means that a connection is specified with identity of the 
requesterNSA and the connection id, maning that a connection id, cannot 
identify a connection :-).


B is actually my favorite, but I can certainly live with A, and that is 
probably the easiest to implement. I dislike C due to the complex 
adressing. A & B means that the address of a connection will be 
providerNSA + connection id. For C, the address becomes providerNSA + 
requesterNSA (creator) + connection id.

Someone might have assumed one of these as a solution (especially A), but 
AFAIK we have never really decided on anything here.


Observations:

The requsterNSA and providerNSA fields seems completely superflorouros (at 
message level, NSA identity is necessary in topology (I think), but at 
message level it just seems silly. An NSA identity and endpoint is also 
more or less the same to me, but this might be HTTP braindamage :-).

In fact, it just confuses things. I can count at least three ways to 
identity an NSA:

1. Their NSA identity (requesterNSA / providerNSA).
2. Their endpoint.
3. Their security identity.

2 and 3 are pretty much neeeded, but I am not so sure about 1.


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at nordu.net>
  Software Developer, NORDUnet