search

solid / authentication-panel

GitHub repository for the Solid Authentication Panel
MIT License
11 stars 15 forks source link

Define JSON-LD context for use with client identifiers #165

Closed acoburn closed 3 years ago

acoburn commented 3 years ago

Resolves #75

As discussed on 3/29/21, this changes the client identifier definition from being a JSON literal to being a first-class RDF-based serialization. This also defines a JSON-LD @context that can be used to bridge the RDF world of Solid and the JSON world of OIDC.

Open questions:

  1. This proposal suggests publishing the JSON-LD context file at https://www.w3.org/ns/solid/oidc.jsonld. I do not have any real opinion about that URL, other than that it should use HTTPS and use a .jsonld extension. Should it instead be published under https://solidproject.org/TR/...?

  2. This PR also refers to an oidc vocabulary which does not currently exist. That vocabulary (once published) would simply define URLs for the various OIDC-related field names. As with the URL for the JSON-LD @context, should this be published under https://www.w3.org/ns/... or under https://solidproject.org/TR/...?

acoburn commented 3 years ago

Using a completely different URL, as the Web Annotation specification does, would be an excellent approach here.

The suggestions above make sense to me:

JSON-LD Context: https://www.w3.org/ns/solid/oidc-context.jsonld Vocabulary: http://www.w3.org/ns/solid/oidc

I do like the .jsonld suffix because it makes this all the more explicit.

ericprud commented 3 years ago

N.B. I've got a PR into jsonld's http-client. The most recent version won't resolve contexts from servers that don't give an application/json content type on .jsonld (e.g. raw.githubusercontent.com or most other legacy server configurations). If this doesn't get resolved, it might be better to use .json to avoid rejecting contexts on most servers.

elf-pavlik commented 3 years ago

@csarven are you ok with merging it now ?

elf-pavlik commented 3 years ago

I think it's ready to merge 👍 Let's give everyone time until the call on Monday morning and we can merge it during that call.

csarven commented 3 years ago

@elf-pavlik , you've been pretty much saying "let's merge" almost at every step ... and about at every juncture, there's been stuff raised which made significant changes to the original PR. Please digest that first. It is not particularly reasonable - IMHO - to expect that everyone is going to review stuff on the weekend and have it ready by "Monday morning". The last commit in this PR was made on a weekend even.. Let everyone know if that's the kind of quality/timeline of reviews you expect... because I have some news for you.. :)

acoburn commented 3 years ago

I am perfectly willing to let this sit longer. I won't be at the 5/31 meeting anyway (US Holiday)