search

w3c / vc-data-model

W3C Verifiable Credentials v2.0 Specification
https://w3c.github.io/vc-data-model/
Other
298 stars 106 forks source link

Is there a problem with retrieval of https://www.w3.org/ns/odrl.jsonld (used within https://www.w3.org/2018/credentials/examples/v1 ) ? #766

Closed mgh128 closed 3 years ago

mgh128 commented 3 years ago

I've tried pasting some of the Verifiable Credential examples into https://json-ld.org/playground

For example, when I paste in the JSON-LD from https://www.w3.org/TR/vc-data-model/#example-6-usage-of-the-credentialsubject-property I'm seeing Processing Error: jsonld.InvalidUrl: Dereferencing a URL did not result in a valid JSON-LD object. Possible causes are an inaccessible URL perhaps due to a same-origin policy (ensure the server uses CORS if you are using client-side JavaScript), too many redirects, a non-JSON response, or more than one HTTP Link Header was provided for a remote context.

Removing https://www.w3.org/2018/credentials/examples/v1 from the @context, the error disappears but some attributes such as "degree" are not mapped to IRIs because they're defined within https://www.w3.org/2018/credentials/examples/v1 .

Retrieving https://www.w3.org/2018/credentials/examples/v1 manually and inserting the content of its @context in place of the URI reference to https://www.w3.org/2018/credentials/examples/v1 still results in the same Processing Error unless I remove the reference to https://www.w3.org/ns/odrl.jsonld .

If I then also manually retrieve https://www.w3.org/ns/odrl.jsonld and insert the content of its @context in place of the URI reference to https://www.w3.org/ns/odrl.jsonld everything finally works fine in https://json-ld.org/playground

So I'm wondering if there is problem with how https://www.w3.org/ns/odrl.jsonld is being served.
When I used curl -v to check the headers, it appears to be served with the correct CORS header and Media Type, so I'm still puzzled.

I also tried converting some of the JSON-LD examples for Verifiable Credentials in http://rdf-translator.appspot.com/ and it struggled to convert more than 3 of the triples.

philarcher commented 3 years ago

Tagging @msporny and @gkellogg on this in case it's a JSON-LD playground issue?? Or, at least, an issue that some debug trace might yield useful info??

msporny commented 3 years ago

Tagging @msporny and @gkellogg on this in case it's a JSON-LD playground issue?? Or, at least, an issue that some debug trace might yield useful info??

@mgh128 -- the example works for me pasted as-is into the JSON-LD playground. I don't have to modify anything.

The error you're seeing seems like a client-side CORS error. That is, for whatever reason, your browser can't download the ODRL file. I checked that file at W3C and the CORS headers are set... but they may be old, or you may have something funky going on w/ your browser. Everything in the JSON-LD playground happens client-side, so the problem might be the retrieval between your browser window and the ODRL context file.

I'm speculating wildly at this point because I can't reproduce your error.

What browser, version, etc. are you using? Are you in any sort of constrained environment (behind an aggressive corporate firewall or sometimes-misconfigured university HTTP proxy)?

/cc @davidlehn @dlongley

mgh128 commented 3 years ago

Hi @msporny

Thanks for investigating. I'm having the problem in the latest version of Chrome (Version 89.0.4389.72) on a MacBook Pro running macOS 10.14.6. However, I'm not seeing the problem in Firefox v86.0 nor in Safari 13.1 - so you're right, it appears to be an oddity within Chrome.

I'm not behind any aggressive corporate or university firewall and the fact that it works for me in Firefox and Safari suggests it's not a firewall issue at my ISP either - just something odd going on in Chrome. I even quit Chrome and only opened minimal tabs (since JavaScript sometimes appears to misbehave in Chrome if too many tabs are open) - but it's still not working in Chrome, so I'll use Firefox or Safari instead.

At least it's working using Firefox or Safari instead of Chrome and we can do the development and testing we need to do. Not sure if any of the Chrome development team are likely to see this issue.

msporny commented 3 years ago

[Broken in] Chrome (Version 89.0.4389.72) on a MacBook Pro running macOS 10.14.6.... it works for me in Firefox and Safari ... not sure if any of the Chrome development team are likely to see this issue.

That's very helpful, thank you @mgh128!

Chrome has been flipping new security switches on as of late that "shouldn't affect anything", but are breaking sites. Sometimes these flags stay flipped on, sometimes they flip them back off in the subsequent release. We tend to put in workarounds as the Chrome team is largely non-responsive to our needs.

My guess is that Chrome changed CORS security behavior in their latest release and now we have to deal with it by either changing the CORS flags at W3C OR fixing some client-side code somewhere. We hate dealing w/ these sorts of problems (because it usually requires us going into the browser code base and hunting around to see what new code they added that would cause this behavior). One Web Platform... bah! :P

Thanks for letting us know Mark... many of us are on Chrome 88, so I expect this will break for us very soon now and there will be a deluge of support requests. Clearly, this is all volunteer time, so we'll get to fixing it when we get to it.

mgh128 commented 3 years ago

Hi @msporny

I'm glad it was helpful to alert you to this, even if it's unwelcome news. I'm fairly sure I was also seeing it when I was still in the last version v88 of Chrome before I upgraded Chrome to v89 within the last hour - so you might even see the issue before you reach v89 of Chrome.

We appreciate your efforts and the efforts of others to fix it when time permits - but no pressure from us. So long as it works in at least one well-behaved browser in the meantime, we can do what we need to do. I'll let my GS1 colleagues know to do their testing in Firefox or Safari if they also run into the same issues in Chrome.

msporny commented 3 years ago

We appreciate your efforts and the efforts of others to fix it when time permits - but no pressure from us.

I appreciate that. It'll get fixed in time -- if we don't fix it, we spend time in Github having discussions like these (which is welcome the first few times it happens... always nice to connect with fellow developers and try to help where we can... but then quickly loses it's luster upon the 15th time we have to explain what's going on and why we haven't fixed it yet). :P

As a relevant aside -- PRs welcome, it's all open source, anyone can put in a fix (and Digital Bazaar not being in the critical path on this is ideal).

I'm fairly sure I was also seeing it when I was still in the last version v88 of Chrome

FWIW, I'm on Chromium 88.0.4324.182 (Developer Build) built on Debian 10.7, running on Debian 10.8 (64-bit). Where is the moon positioned in the sky where you are... and is Jupiter in alignment with Saturn? We've heard that can affect CORS pre-flight checks. :P

davidlehn commented 3 years ago

I did a quick test last night and it worked. Today I got around to testing on more browsers and everything worked. So I'm not sure what might be wrong. It's more difficult to test these days since I think all browsers decided in their infinite wisdom that CORS preflight OPTIONS requests are to be hidden. Or at least I don't see them anymore. That makes it difficult to even debug if CORS is doing anything.

One difference is that https://json-ld.org/ns/odrl.jsonld is returning "access-control-allow-origin: https://json-ld.org" vs just "*" for other requests. But since this is on the playground, I'm not sure why that would cause a fault.

I'm not sure how to fix this without being able to see the problem or even see what the behavior is that might cause the problem. Maybe if you can see the issue in the network debug panel you could save and attach the HAR trace file?

mgh128 commented 3 years ago

Hi @davidlehn Thanks for the follow-up. I think I've done what you suggested and have attached the console log and the HAR trace file. The console log does mention a CORS problem in the log:

(index):1 Access to XMLHttpRequest at 'https://www.w3.org/ns/odrl.jsonld' from origin 'https://json-ld.org' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. playground.js:1163 jsonld.InvalidUrl: Dereferencing a URL did not result in a valid JSON-LD object. Possible causes are an inaccessible URL perhaps due to a same-origin policy (ensure the server uses CORS if you are using client-side JavaScript), too many redirects, a non-JSON response, or more than one HTTP Link Header was provided for a remote context. at https://cdn.jsdelivr.net/npm/jsonld@3.2.0/dist/jsonld.min.js:37:38296 at c (https://cdn.jsdelivr.net/npm/jsonld@3.2.0/dist/jsonld.min.js:37:15087) at Generator._invoke (https://cdn.jsdelivr.net/npm/jsonld@3.2.0/dist/jsonld.min.js:37:14840) at Generator.throw (https://cdn.jsdelivr.net/npm/jsonld@3.2.0/dist/jsonld.min.js:37:15446) at r (https://cdn.jsdelivr.net/npm/jsonld@3.2.0/dist/jsonld.min.js:1:8488) at u (https://cdn.jsdelivr.net/npm/jsonld@3.2.0/dist/jsonld.min.js:1:8735) (anonymous) @ playground.js:1163 www.w3.org/ns/odrl.jsonld:1 Failed to load resource: net::ERR_FAILED

json-ld.org-1614976372840.log

json-ld.org.har.txt

davidlehn commented 3 years ago

@mgh128 Looks like CORS headers are not in the odrl response. Not sure how accurately that HAR file captures what happens. Using the "Copy as cURL" command shows it returning different headers. Suggestion was it may be a Chrome 89 issue, maybe due to their COOP, COEP work? @dlongley also reported a failure in Chrome 89ish.

I just used this as an excuse to install/update browsers and this all worked fine in:

I think I've exhausted my ability to reproduce the issue. Hopefully someone with the problem can try to debug it. Maybe w3.org caches are acting goofy depending on the request source? Maybe try again every so often and see if it is nondeterministic?

Simplified playground test cases:

mgh128 commented 3 years ago

@davidlehn Thanks for the further testing. I've just tried your two links above for indirect ODRL load vs direct ODRL load. Both work fine in Firefox 86.0 and in Safari 13.1. Both fail with four identical Processing Errors displayed in JSON-LD playground when I try in Chrome 89.0.4389.72 on my Mac, running macOS 10.14.6. I don't desperately need it to work in Chrome, so long as it works reliably in Firefox - we'll just use that for our testing/development until Chrome sorts itself out, whenever that is.
Thanks again to you and @msporny for your help today.

dlongley commented 3 years ago

It seems to be a caching problem. I was having the same problem (on Chrome 89) where the access-control-allow-origin header was not present on the response. I opened the devtools in Chrome and clicked Disable Cache. Then I tried again and the odrl context loaded properly. After re-enabling cache I could no longer reproduce the problem.

kdenhartog commented 3 years ago

It seems this is an issue with chrome rather than something to do with the way it's published on W3C. I'm going to propose closing this since I don't see any action items that we can do at this point.

brentzundel commented 3 years ago

No comments since marked pending close. Closing