Update message type and protocol identifier URIs to https

[troyronda]

With the consensus in the Aries WG call to update protocol URI to use https, our next step is proposing a concrete mechanism. The prior discussion on this topic was held in #129

We would like to use a Hyperledger Aries URI string such that:

• browses to the appropriate protocol documentation.
• protocol documentation is up-to-date with the GitHub repo hyperledger/aries-rfcs

Example of protocol type URI:

• https://aries.hyperledger.org/rfcs/didexchange/1.0/invitation

Example of redirecting to the source documentation (for the above):

• https://aries.hyperledger.org/rfcs/didexchange/1.0/ -> https://github.com/hyperledger/aries-rfcs/blob/master/features/0023-did-exchange/README.md
• A nice-to-have would be including the suffix as a fragment (e.g., https://github.com/hyperledger/aries-rfcs/blob/master/features/0023-did-exchange/README.md#Introduction).

Some options to explore for hosting:

• GitHub Pages
• Redirect to GitHub markdown page
• Read the Docs
• Hyperledger web server

Also need to check with Hyperledger to explore registering the aries.hyperledger.org subdomain.

[dhh1128]

I have opened a conversation with HL's community architects about how to approach the rewriting/hosting/redirection feature that we need. I will report back.

[dhh1128]

Update: Hyperledger IT is asking us for nginx rewrite rules. I am working on it.

[troyronda]

@dhh1128 Thanks very much for your efforts. Are there any updates to share for this topic?

I know it's not directly coupled, but it would be good to update the message types before we get too far down the path of community interop claims discussed in the test suite issue (#220).

[dhh1128]

I'm stalled again. I could give HL IT people nginx rewrite rules, using either of two strategies:

1. HTTP 301 redirects from aries.hyperledger.org/something to github.com/hyperledger/aries-rfcs/something -- aries.hyperledger.org never serves content, but redirects 100% of the time.

2. aries.hyperledger.org hosts static content and uses redirects to expand short URIs into long ones.

Strategy 1 requires less work by HL IT, but causes content to be penalized in Google's PageRank.

Strategy 2 requires HL IT to allocate a web server, and it means we have to modify our repo's CI/CD to generate static content.

It is not obvious which we should do.

But what stopped me isn't this question. At IIW, there was intense discussion about taking DIDComm (not all Aries RFCs, but just the RFCs that sit below the level of application protocols, such as the encryption envelope and routing stuff) to a formal standard at a place like IETF. If we did this, the namespaces at the front of message type URIs probably should not contain a reference to Hyperledger (or to DIF, which wants to host DIDComm work during SDO-oriented spec development). Which means a lot of the change we're trying to do here needs to change again, sometime soon (Aargh!), or else we need to anticipate where it will end up and change to that, instead of to a URI like aries.hyperledger.org.

Right now, what I'm thinking is that we change to "didcomm.org/protocolname/version". This would take an organizational sponsor entirely out of the URIs. I just went and registered didcomm.org in case we want to do that, and we can give the domain to HL for now, DIF if the locus changes, and IETF or another SDO farther down the line if we get there.

But this has problems: A) it's not identical to what the community agreed to (aries.hyperledger.org); B) it is only relevant to didcomm, not to all Aries RFCs.

So I'm kind of scratching my head again. Sorry to get stuck so easily.

@TelegramSam

[dhh1128]

Update on this: we decided to use didcomm.org as the prefix, with static content served from a webserver owned by HL. Now working on it with HL IT. Ticket: https://jira.linuxfoundation.org/servicedesk/customer/portal/2/IT-17759

[kdenhartog]

Should we close this issue now, or would it be preferable to wait until the ticket is completed?

[dhh1128]

Let's keep this open until the work is closer to closure. The IT ticket referenced above has now been replaced with a newer one that has more clarity around tasks: https://jira.linuxfoundation.org/servicedesk/customer/portal/2/IT-18070

[llorllale]

@dhh1128 hello, what's the status? I don't have permissions to view that issue on LF's Jira.

[llorllale]

Another question just raised on the call is what the final URI would look like? Is it still going to look like https://didcomm.org/protocolname/version?

[troyronda]

@llorllale That was my understanding.
@dhh1128

[swcurran]

When I updated the RFC I checked and the three RFCs that use the message type prefix - DID-Exchange, Introduce and Help-Me-Discover - use the format you have above. Daniel also indicated that was the correct format in feedback on the community collaboration RFC.

I'd say we declare it official and say that's the format. Then I think we can close this.

I would still like to have a way for https://didcomm.org to point to actual documentation, but that's for the future when there is time for that.

[dhh1128]

@troyronda : the second IT ticket with the LF was closed by the IT people because they decided they wanted HL to host the web server, instead of them. This was frustrating, because they had asked HL people to defer to them in the first place.

Ry, being his typical helpful self, has offered to close the loop at HL. However, now that we know the didcomm subtopic is moving to DIF, I'm wondering if we should just let DIF host the docs instead.

[TelegramSam]

Continue Issue here: decentralized-identity/didcomm-messaging#23

[davebryson]

For clarity, does this change just apply to Sovrin DIDs or all DIDs??

[swcurran]

This is not a change to DIDs but to the identifier used for message types in Aries. When an Aries agent sends a message (say, "Here is a credential offer"), it uses an "@type" field with a string identifier in it. This change is to make that identifier a string based on an HTTP address instead of a DID.

[davebryson]

Thanks. Right. So a DID is no longer a valid doc_uri correct?

[swcurran]

It is deprecated, but still in use. There is a community effort to move away from it that has stalled. @TelegramSam -- second time this week this has come up. We should push this. Ready for step 2?

See: https://github.com/hyperledger/aries-rfcs/tree/master/features/0348-transition-msg-type-to-https