Add explicit support to account-porting-1_0 for porting within the same OP

[Marcos Sanz]

There are situations in our deployment where the "Old OP" is at the same time the "New OP", those have been explained in the list. The draft certainly allows for this, but there's an unnecessary overhead there (for the OP to issue the enc_port_token and to run additional endpoints, additional roundtrips in the workflow, etc.).

It'd be a very useful and easy feature if the OP could deliver the old sub right ahead in the ID token. Different possible syntaxes have also been mentioned

   { "sub":"new789", ..., "subs": ["old123", "old456"] }

or

   { "sub":"new789", ..., "aka": {"subs": ["old123", "old456"]}}

or

   { "sub":"new789", ..., "old": [ { "sub":"old123", "remove":true}, {"sub":"old456", "remove":false } ] }

For our use case the "remove" indication is not necessary, and thus options 1 and 2 are just fine, but it's maybe wise to already plan for this signaling.

[Bjorn Hjelm]

There are situations in our deployment where the "Old OP" is at the same time the "New OP", those have been explained in the list. The draft certainly allows for this, but there's an unnecessary overhead there (for the OP to issue the enc_port_token and to run additional endpoints, additional roundtrips in the workflow, etc.).

It'd be a very useful and easy feature if the OP could deliver the old sub right ahead in the ID token. Different possible syntaxes have also been mentioned

   { "sub":"new789", ..., "subs": ["old123", "old456"] }

or

   { "sub":"new789", ..., "aka": {"subs": ["old123", "old456"]}}

or

   { "sub":"new789", ..., "old": [ { "sub":"old123", "remove":true}, {"sub":"old456", "remove":false } ] }

For our use case the "remove" indication is not necessary, and thus options 1 and 2 are just fine, but it's maybe wise to already plan for this signaling.

[Bjorn Hjelm]

There are situations in our deployment where the "Old OP" is at the same time the "New OP", those have been explained in the list. The draft certainly allows for this, but there's an unnecessary overhead there (for the OP to issue the enc_port_token and to run additional endpoints, additional roundtrips in the workflow, etc.).

It'd be a very useful and easy feature if the OP could deliver the old sub right ahead in the ID token. Different possible syntaxes have also been mentioned

   { "sub":"new789", ..., "subs": ["old123", "old456"] }

or

   { "sub":"new789", ..., "aka": {"subs": ["old123", "old456"]}}

or

   { "sub":"new789", ..., "old": [ { "sub":"old123", "remove":true}, {"sub":"old456", "remove":false } ] }

For our use case the "remove" indication is not necessary, and thus options 1 and 2 are just fine, but it's maybe wise to already plan for this signaling.