Re: Comments

Hello,

 

The aim as I mention is to clarify the scope of ODRL in the end-to-end ecosystem (mostly the word “authorisation”, which is used by OIDC/authentication and can also be used in the rights/entitlements space). The 3 questions were taken from a OIDC page, I just put them in boxes around my proposed understanding of the ecosystem, but nonetheless, “you” is always an agent (or “the agent”).

 
We’re not into verification/proof – precisely the point: that’s an authentication problem (scope of OIDC) – but it is important to know the relationship 
That’s on the execution and part of the conversation about the contents of the state of the world, this just describes the relationships (“identity -> entitlements -> digital assets”), if an account/identity is connected to a state of the world identifier (did:odrlw) that means they can access it (as per the diagram, 2 claims are connected to 1 did – for example your “whole” email could be accessed by 2 accounts if you’ve authorised them)
That process, I think it is also part of the OIDC scope – ODRL has no way of validating an interaction is from the agent (neither do any system outside an authentication one – they all “trust” that check happened in previous stages).
 

Odrl:Request is defined in the ontology (not sure why not elsewhere, perhaps because it is non-normative?):

 

skos:definition "A Policy that proposes a Rule over an Asset from an assignee."@en ;

        skos:note "A Request Policy  MUST contain a target Asset, a Party with Assignee function, and at least one of a Permission or Prohibition rule. The Request MAY also contain the Party with Assigner function if this is known. No privileges are granted to any Party."@en ;

 

 

I don’t understand the use case where you can interface with an asset/asset provider and propose which rules you will follow, many steps must have taken place for you to be at that point in the supply chain.

 

I had a conversation with someone last week where a “security issue” was the vocabulary of actions (fine-grained compared to rules), and those need to be public to build functionality, but ‘specific’ to the assets and connected to rules. i.e. in an asset from dcat dct:right (Information about rights held in and over the resource) could be the list of actions that can (potentially) be associated with odrl:Rules inside odrl:Offer to become odrl:Agreement which closes the loop with the odrl:hasPolicy attribute used by dcat. You can see this everywhere (Amazon’s S3 publishes all the actions, associated to their assets, it is up to the policy creator to determine which ones are valid).

 

Regards,

___________________________________

Joshua Cornejo

marketdata

smart authorisation management for the AI-era

 

From: Rui Zhao <rui.zhao@cs.ox.ac.uk>
Date: Monday, 19 May 2025 at 11:39
To: <public-odrl@w3.org>
Subject: RE: Comments
Resent-From: <public-odrl@w3.org>
Resent-Date: Mon, 19 May 2025 10:39:44 +0000

 

Hi Joshua,

I'm learning to be an expert in ODRL but am not yet. But based on my existing understanding, the question mark makes things complicated, because it can be interpreted in any of the three ways: (e.g., "can you access this?", where "you" is the agent)

1. A *verification/proof* of the agent saying the agent can access which range of data (with which set of policies, same below);

2. A *request* from the agent wanting to access a range of data;

3. A *process* for the user/system to verify that the agent can access a range of data.

 

Not sure which one is the context referring to? It appears to be inconsistent.

 

Actually, this relates to a question I have for ODRL: how can I represent a *request* saying I want to access a certain range of data *and* the corresponding rules I will follow? It appears there is no such a subclass of `Policy` to represent this? (I see the `Request` class in the GH issue linked, but it is not in the standard ODRL 2.2 terminology, right?)

 

Best,

Rui

 

From: Víctor Rodríguez Doncel <vrodriguez@fi.upm.es>

Sent: Monday, May 19, 2025 at 11:16 AM UTC+1

To: public-odrl@w3.org

Subject: RE: Comments

 

Hi Joshua, 

Well, from the figure alone I can get no full understanding --and I am afraid I don't know the OICD technology...
I understand Open ID for Verifiable Credentials is part of the EUDI Wallet Architecture, but I don't know what is the role of ODRL --maybe you or Beatriz, if she knows more, can present the framework during one meeting...

Regards,
Víctor

El 16/05/2025 a las 16:25, Joshua Cornejo escribió:

Hi,

 

Aiming at clarifying some language for consistency, OIDC uses the term “authorisation” to cover the “can you access this” and to a limited extent “what can you do inside”.

 

This is in monitoring or access control for an agent, not upstream contract negotiation (not converting odrl:Offer -> odrl:Agreement).

 

Comments/thoughts appreciated.

 

 

 

___________________________________

Joshua Cornejo

marketdata

smart authorisation management for the AI-era



-- 
Víctor Rodríguez-Doncel
D2110 - Ontology Engineering Group (OEG)
Departamento de Inteligencia Artificial
ETS de Ingenieros Informáticos
Universidad Politécnica de Madrid
https://cosasbuenas.es
 
Warning about the confidentiality of communications: the content of this e-mail and its attachments is strictly confidential. Any unauthorized copying, disclosure or distribution of the material in this e-mail is forbidden.
-- 
Rui Zhao
Postdoc @ EWADA (Ethical Web And Data Architecutres in the Age of AI)
Human-Centred Computing, Dept. Computer Science
University of Oxford
https://me.ryey.icu