Re: Security profile for ODRL

This was part of the reason why we dropped the “Security” section from ODRL V2.*

But, we can as a Community Group publish Best Practice reports that can assist the wider ODRL user base.

Renato

> On 24 Jul 2020, at 09:53, Amit Kapoor <amit.kapoor@jerichomusiclabsllc.com> wrote:
> 
> Hi Victor,
> 
>  Comments inline:
> 
> On Thu, Jul 23, 2020 at 08:22:57AM +0200, Víctor Rodríguez Doncel wrote:
> <snip>
>> 1. Perhaps serialize as RDF/XML and use XML Digital Signature
>> 2. Perhaps serialize as RDF/XML and use XML Encryption
> 
>  Yes, and thanks for reminding me that JSON is not the only format
>  supported by ODRL. That does bring up some interesting issues.
>  Example, how would one do that in Turtle format?
> 
>  Is there a canonical representation for ODRL? That might be useful for
>  digital signature calculations.
> 
>> Hence, I don't really see the need to have intrinsic elements to do this.
>> But again, this is my personal, and not very well educated opinion.
> 
>  I myself don't have a very well defined use-case at the moment for
>  encrypted intrinsic elements, but suspect DRM might require the same.
> 
> regards
> <snip>
>> El 23/07/2020 a las 0:10, Amit Kapoor escribió:
> <snip>
>>>   I was wondering what the recommended options are for security around
>>>   an ODRL document(?). There are at least two use cases that I can think
>>>   of:
>>> 
>>>   1. Integrity of the entire document (JWT or Verifiable Credentials?)
>>>   2. Embedding of private information within a ODRL document (JWT?)
>>> 
>>>   ODRL 1.1 had some ideas for this, but the details for 2.2, I believe,
>>>   still need to be finalized. Is there enough interest here to get this
>>>   defined as part of the standard or as an extension?
> <snip>
>

Received on Friday, 24 July 2020 05:43:00 UTC