Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial feedback on major sections: Interface bindings (HTTPS) #83

Open
peacekeeper opened this issue Jul 29, 2024 · 4 comments
Open

Initial feedback on major sections: Interface bindings (HTTPS) #83

peacekeeper opened this issue Jul 29, 2024 · 4 comments
Labels
pending-close Issue will be closed shortly if no objections

Comments

@peacekeeper
Copy link
Collaborator

peacekeeper commented Jul 29, 2024

During the 25th July 2024 DID WG call, I mentioned "Interface Bindings (HTTPS)" as one of four major topics for this spec. See here:

The idea of this section is to define the DID Resolution and DID URL Dereferencing functions not just in abstract way, but also a concrete binding for invoking those functions via an HTTPS API, including how parameters, headers, status codes, etc. are used.

Any feedback is welcome, and I'd be most interested in high-level opinions on whether this is indeed an important topic that should be covered by the spec, and in thoughts on the general direction of this topic.

@jandrieu
Copy link

Yes. I think this a mandatory-to-implement https binding in order to achieve cross-method interoperability.

@pchampin
Copy link
Collaborator

This was discussed during the WG meeting on 2024-08-22:
https://www.w3.org/2024/08/22-did-minutes.html#t12

@mccown
Copy link

mccown commented Sep 13, 2024

I agree. https should be mandatory to implement and used in all of the examples. However, I was researching how Apple handles the situation.

In recent years, Apple has required https for all connections. However, they realize that there may be some isolated situations where insecure http may be required and have defined a key called 'NSAllowsArbitraryLoadsInWebContent', which can bypass standard protections in some instances. If insecure http connections are allowable, then I would propose it be handled explicitly with an exception designator. This way, whenever it's deemed necessary by implementors, it will be an overt decision and something that could be highlighted to users or other services.

https://developer.apple.com/documentation/bundleresources/information_property_list/nsapptransportsecurity/

@peacekeeper peacekeeper added the discuss Needs further discussion before a pull request can be created label Sep 23, 2024
@peacekeeper
Copy link
Collaborator Author

Marking as pending-close, since this has been discussed on a high level.

For now, one concrete issue has been identified related to this topic:

@peacekeeper peacekeeper added the pending-close Issue will be closed shortly if no objections label Oct 25, 2024
@peacekeeper peacekeeper removed the discuss Needs further discussion before a pull request can be created label Nov 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pending-close Issue will be closed shortly if no objections
Projects
None yet
Development

No branches or pull requests

4 participants