How should a byte steam be encoded into JSON for a dereferenced Did URL that points to an external resource outside the DID Document? #129
Comments
At present, the test suite isn't designed to do this and probably won't get that functionality by the time CR ends. If someone needs this functionality, they will have to come up with a PR to support it. @peacekeeper might have done more thinking on this since that's his part of the test suite. |
|
The proposed method I've been working towards is converting the data to a data URI. So for a image/jpeg it will be |
|
@kdenhartog I am not sure I understand the question. But, I may have been working on similar solutions. Are you wondering how to embed arbitrary data in a JSON object? Or do you want to put arbitrary data in your DID Document, such that said data gets returned when the right DID-URL is dereferenced? You could put the data in a data: URL and put that data:URL as a service endpoint, but I wouldn't recommend it. I am confused, in part, because embedding != external resource, so I think I lost what you were trying to get at. What's the use case you're trying to solve for? |
|
Currently the way that we have to provide the input and outputs for our test results have to be encoded into A JSON object for dereferencing. As an example |
Yes, this works @kdenhartog -- and given that no one else has proposed something, and that what you're suggesting should work for the purposes of the test suite, we're good. I'm not sure we need to test this as a part of the test suite, though? Is there a dereferencing test that would exercise this capability? |
|
So, this is something I've been doing a lot of work with recently. My opinion is that data: urls are insufficient for a number of reasons, BUT they can work in many instances. The problem is that data:urls only provide a media-type for content description. It doesn't provide for alternative encodings, compression, or encryption. See the Learning and Employment Record for an approach that embeds arbritary content in JSON-LD. https://drive.google.com/file/d/1RfdXAUNhp0kluD9htpb8c_Tg2dLm2QcJ/view) FWIW, there is also a new property for DID Documents I've been working on called "LinkedResources" which may be a better way to do what you're trying to do. It's supported by DID-core and will be submitted to the DID Spec Registries, but is not ready for submission as we are proving out the concept with multiple implementations before socializing. Ping me separately if you'd like to learn more. I'm still confused by your use case however. Taking your example, should map to which results in a stream of bytes. In order to put this data into I'm not following this last bit at all. It seems like you are testing a method-specific dereferencing semantic with a parameter that is not well defined (highlighting the tribal wisdom issues already raised). My interpretation of how one would process your proposed did is this:
Note, currently there are only two service types listed in the did spec registries, so the value of the "type" property is ambiguous, but that type property should definitively explain how you work with that service endpoint. I just made up a type that I am interpreting as saying this is a normal web link which is intended to work correctly when you append the RelativeRef property. Continuing the flow: In this flow, I don't understand why there is any confusion about what gets put into executions.output.contentStream, in part because it seems that it MUST be whatever is returned in the payload for that gif, and presumably the header data from that retrieval gets mapped to contentMetadata. And this is entirely the responsibility of the resolver--not a function of DID Core. How and what you put into that dereferencing response is currently method-specific and otherwise pre-standards track with the DID Resolution spec. Personally, I would not build out an implementation this way. I would simply take the DID Document, transform the DID-URL into a URL with the service property semantics, and then dereference that URL. In particular, IMO, should work in any DID enabled browser to actually render that image. We have so much implemented in web libraries that the current dereferencing semantics don't make much sense to me. What I think we need is for dids to be usable as URLs, full stop. We probably don't want to do that by reinventing dereferencing, we want to do that by defining outputs that standard browser agents can use. Sure, you can also create bespoke dereferencing (such as pulling something from the chain) that, would by its nature, be method-specific, but this pattern of transforming a DID-URL into a URL is going to be vital for a reasonable transition of current web-centric applications to DID-aware applications. The actual dereferencing in that vast array of use cases should just use standard web dereferencing. So, let me try the use case question again. What is the real-world value-creating interaction that you are trying to enable? The IMG tag example above doesn't need the dereferencing API and will likely never use a DID resolver to do the dereferencing. Further, the dereferencing contract is stated in an abstract form. You're basically asking for a non-abstract solution, which is out of scope for DID-Core, IMO. On the other hand, I would love to see a test using a data URL for a service, which returns the image via http (although I still feel that is testing the resolver and not did-core): (fwiw, that is the data:url for the gif at https://i.imgur.com/JwIZJYD.gif |
My intent was to add one to show the usage of |
A DID URL that behaves like a PURL.
Certainly, but it requires a DID enabled browser which we don't currently have.
Agreed. Only reason I'm having to produce a non-abstract solution is because something needs to go in the
Yeah I do think we're quite close to heading into resolver land so saying this must be done in some normative way is incorrect in my eyes. I'm more just heading in the direction of "What do I put in there when the DID URL references an external resource... oh I'll just put an encoded string in there since it at least fits in a JSON object". I suspect others may head in a different direction which is fine until DID Resolution defines how this should work. |
|
@kdenhartog wrote
To be clear, it only needs an http request library, which are available in just about every language on every platform. You don't need a full browser. |
While that's true http libraries are really all that is needed, we also don't support DID URLs at the moment either. Hence the need to find a way to transform a DID URL to a HTTP URL when fetching an external resource not contained within the DID Document so that we can glue the two concepts together. |
|
@kdenhartog few comments..
Retrieving the binary GIF data would then be a second (purely HTTP based) dereferencing process. This may be more consistent with how today's HTTP-based PURLs work, which redirect you to a resource and trigger a second dereferencing process, rather than returning the resource itself in the first step. But these details are really out of scope for DID Core and we should collaborate on DID Resolution to specify this. |
Was happy to convert to to hex, but prefer your proposal in number 5 instead. Will go with that.
I actually way prefer this methodology. Will go in this direction instead and implement the test to behave in that way as well.
+1 agreed |
|
@peacekeeper in order to comply with a few of the already written tests I had to modify the output to be: Does that work for you? My implementation is passing all the tests now with this change. |
|
@kdenhartog yes I like this! You're right, my earlier example was incorrect, since the dereferencing part of the spec says that |
Currently the only examples in the test suite for the
executions.output.contentStreamproperty in the dereferencer data model input is stringified JSON. How should we encode a different media type such as image/jpeg into the result?The text was updated successfully, but these errors were encountered: