Using GNAP roles

[elf-pavlik]

Grant Negotiation and Authorization Protocol (GNAP) uses following roles:

Authorization Server (AS)

server that grants delegated privileges to a particular instance of client software in the form of access tokens or other information (such as subject information).

Client

application operated by an end-user that consumes resources from one or several RSs, possibly requiring access privileges from one or several ASs.
Example: a client can be a mobile application, a web application, etc.

Note: this specification differentiates between a specific instance (the client instance, identified by its unique key) and the software running the instance (the client software). For some kinds of client software, there could be many instances of that software, each instance with a different key.

Resource Server (RS)

server that provides operations on protected resources, where operations require a valid access token issued by an AS.

Resource Owner (RO)

subject entity that may grant or deny operations on resources it has authority upon.

Note: the act of granting or denying an operation may be manual (i.e. through an interaction with a physical person) or automatic (i.e. through predefined organizational rules).

End-user

natural person that operates a client instance.

Note: that natural person may or may not be the same entity as the RO.

I see it as a good start. We most likely will need another role when we speak about more advanced delegation. For example:

• ACME (organization) acting as Resource Owner grants access to an employee Bob (person)
• Bob (person) acting as ??? further delegates some of that access to Omni (organization)
• Omni (organization) acting as ??? further delegates some of that access to an employee Alice (person)
• Alice (person) acting as End-User further delegates some of that access to an application Projectron (application) acting as Client

In that case ??? fits a little bit Resource Owner definition but I would like to keep it clear who actually owns the resource (in our case just ACME). They don't fit End-user since they just delegate their access in this scenario, in other scenarios they could act as End-user as well. Also End-user definition doesn't seem to include organizations, while they can't manually operate a client instance, they could still have some automation (eg. bots) operating on behalf of the organization.

[woutermont]

I would like to keep it clear who actually owns the resource

Can you elaborate on what kind of 'ownership' you have in mind when using that verb?

At Digita, we mostly work around the roles of data producers, data custodians and data consumers, which naturally fits one axis of data roles: where data comes from, where it is located, and where it goes to. Access to data is another axis, which is set (~ produced), regulated (~ located), and received (~ consumed). The GNAP roles seem mostly to fit those axes:

• data producer = ?

• data custodian = resource server

• data consumer = end-user, client or the end-user+client combination

• 'access producer' = resource owner

• 'access custodian' = auhorization server

• 'access consumer' = end-user, client or the end-user+client combination

The only role that seems to be missing in GNAP is that of the data producer, so in that sense there might be some 'ownership' missing (one that, just like resource owner, can possibly overlap with end-user). Is this what you are hinting at, @elf-pavlik?

[elf-pavlik]

I think this is not fully defined but I see direction of having specific owner of each solid storage. That owner of the storage, has full implicit control over all the data in that storage.

ACP: 5.3. Access control resource editing

The owner of a storage is implicitly considered an owner of all the resources in the URI space corresponding to storage.

In that case the owner can migrate to another storage provider etc.

When it comes to your data producer we have also data creator role - the End-user who created the resource. Still in many cases, for example storage owned by an organization, the organization would be the owner while some person would be the creator.

[woutermont]

The owner of a storage is implicitly considered an owner of all the resources in the URI space corresponding to storage.

That's not really a solid definition (no pun intendend): since a storage is also just a resource, it is (non-visciously) circular. Moreover, ACP defines acp:owner as an agent credited as the owner of a resource, which is also not really helpful. Who "owns" a resource, i.e. what does this "owning" mean; or when is it right to use that predicate? ACP does not state whether there are other ways to become an acp:owner except by being the acp:owner of the storage. Nor does it define who "owns" as storage. The identity that first created it? The organization hosting it? (Any large enough group of shareholders in that organization? Just to say implicit control goes a long way.)

I was trying to work out the distinction this 'implicitness' entails. The only thing I could come up with is that the control access of the implicit owner (acp:owner?) can impact the access of other resource owners, but not vice versa. Is it this difference you want to express? If so, why does ACP contain an acp:OwnerAgent matcher, given that it would not be able to restrict anything?

[bblfish]

You may also want to look at the European Self Sovereign Identity Foundation (ESSIF) lab Glossary, that have put a lot of work in creating some comprehensible definitions.