Same host-URL, but different Name for connection use-case

[Oran-Dan]

The discussion arose in this PR: #157

Summary:
An organization might use the same domain URL but still want to connect with others using different names.

Example:
University X wanting the connect with you in the name per relevant course, even if all the courses are for the same study (Modular Education) -->
First connection
connection.url: university_x.com
connection.name: Algebra I
Second connection
connection.url: university_x.com
connection.name: Geometrics

Currently this is treated as different connections since name and url have to be the same
In this case a student will have perhaps 18 different connections per year for his single bachelor in math.

---

Relevant comments (from the above-mentioned PR) on this use-case:

[nanderstabel]

The implementation in this PR is not the definitive solution for this problem of identifying Issuers/RelyingParties, but it is just slightly better than the previous solution:

"name" is not unique, any Issuer can come up with a name, or duplicate another servers name.

previous solution = connection ID based on "name"
current solution = connection ID based on "name" AND "url" (host url)

There are three scenario's:

Same issuer, but with subdivisions
Issuer 1: { name = "subdivision_A", url = "issuer_a.com" }
Issuer 1: { name = "subdivision_B", url = "issuer_a.com" }
previous solution --> two different connections ✅
current solution --> two different connections ✅

Issuers are completely different
Issuer 1: { name = "Issuer 1", url = "issuer_a.com" }
Issuer 2: { name = "Issuer 2", url = "issuer_b.com" }
previous solution --> two different connections ✅
current solution --> two different connections ✅

Issuer 2 is trying to impersonate Issuer 1?
Issuer 1: { name = "Issuer 1", url = "issuer_a.com" }
Issuer 2: { name = "Issuer 1", url = "issuer_b.com" } <-- potentially a scammer?
previous solution --> cannot make a distinction between Issuer 1 and Issuer 2 ❌
current solution --> two different connections ✅

So to sum up:

name is not inherently a unique identifier
the host of a url is

[nanderstabel]

And to add a bit more: in this current change we use the hostname of the url as an identifier. So:
"https://university.com/subdivision_A" 's hostname --> university.com
"https://university.com/subdivision_b" 's hostname --> also university.com

So if the university wants to issue credentials from different subdivisions, then it will need the "name" identifier to make the correct distinction.

[Oran-Dan]

Clear, and i think the set-up as you set it out is great.
The scenario i'm specifying is actually one in which scenario 1 will happen so often that one student will have about 6 new connections per semester and (based on my previous study) about 18 connections per year from his Uni.
I do think this is a plausible future as Modular Education was one of the big keypoints in the KWC1 meet-up/workshop I attended nearly 5 months ago.
Perhaps another issue but how do we prepare for this?

[nanderstabel]

There's no clear cut way of uniquely identify issuers/relyingparties in a way that covers all edge cases so think it's best to wait and see what will happen in the real world regarding these kind of things. We simply don't know yet whether a scenario like the one you describe would happen.

But, since we're on the topic I also want to mention this:
In SIOPv2/OID4VP there actually is a standardized way of uniquely identify clients (Relying Parties) namely by the use of their client_id (Client Identifier). There are multiple different methods for this: https://openid.net/specs/openid-4-verifiable-presentations-1_0-20.html#name-verifier-metadata-managemen
One of them is using DIDs for the Client Identifiers, which is what we currently focus on.
In OID4VCI there is a standardized way of uniquely identifying Issuers, namely always by use of a case sensitive URL: https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-13.html#name-credential-issuer-identifie

So that's great, their Identifiers are standardized, however, they're not fully compatible with each other. So when a University is both A RelyingParty, as well as an Issuer, then they would potentially communicate two different Identifiers with us, e.g. a DID and a case sensitive URL. So we would treat them as two separate Connections.

There are some methods to validate that a DID is linked to a hostname: https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-13.html#section-13.4-3.1
But this is optional and doesn't cover all of the issuer/client ID mismatches.

So the way of identifying Connections is definitely not optimal, but it works with NGDIL and the current real world application that are out there (which is very limited).