Opaque / Non opaque access token

[fimbault]

Currently we assume that tokens are opaque to the client, meaning that the client doesn't care about their internals (although in practice JWT is often used). It's even described as such in our current version of the terminology (v02) : "The contents and format of the access token are opaque to the RC."

Yet, there has been discussion on the IETF mailing list that for privacy reasons, there might be a need for non opaque tokens, so that its content can be verified (i.e. doesn't include more rights than requested).

Related actions : do we want to support non opaque tokens?
1) review the potential impact on the definition of "access token" in #29 2) should we define a datastructure for GNAP access tokens? (JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens or equivalent). How do we keep flexibility if one needs to extend the default format (more fields), or even integrate with something different than JWT? (we don't want to limit potential innovation here). 3) does it replace introspection/management endpoints? 4) should it be enforced? is it just an option?

[jricher]

I am against the client having any expectation of being able to understand the access token. If a component needs to send a message directly to the client in the way the client can understand it, then it should use a different protocol element to do so.

The common trust model in the OAuth world is that the client is the untrusted component, which is why it needs to get the access token in the first place.

[fimbault]

I have mixed feelings here. I agree with the client being unstrusted from a security perspective, what we're saying here is that the AS is untrusted from a privacy perspective.

To me, the biggest potential downside of non opaque tokens is that it potentially limits innovation. A big part of the success of JWT comes from json's flexibility. Plus nothing stops me in OAuth from using a completely different format if I wish. That's really valuable. My current experience here would be to keep that behavior. But it does come at the expense of not having a schema that can be verified by default, which could come handy in some cases. The alternative is introspection/management APIs, but there's always the possibility that the token could actually be different than the related resource description.

So to go forward, I guess Denis should make its case here, and then we can take a decision. This should also balance the alternatives.

[jricher]

It's also a privacy issue to release information to the client in many cases. Several profiles of OAuth that I've worked on prohibit the token itself to carry user information or identifiers in a way that the client could read. In these cases, it's the business of the RS and the AS, and the token is just the artifact to carry rights between them.

For example: in a medical space, the AS knows the user's account and the medical record number associated with that account. The RS just needs to know the medical record number. The client doesn't need to know either of those if it's given an appropriately scoped API and access token. None of that is possible if the token is not opaque, even optionally.

I think it might be better to approach these privacy and rights concerns by clarifying things like what gets returned alongside the access token itself, instead of inside the access token. (see #141 for one slice of this) This fits the model I mention above of sending information alongside the access token specifically for the client to consume, instead of assuming the client can look into or otherwise interpret and understand the access token itself.

[fimbault]

That's true indeed

[aaronpk]

Editor's hat off, I am 100% against the idea of letting/requiring clients interpret the contents of access tokens. Justin did a great job of illustrating examples and reasons of why.

[yaronf]

Can we allow non-opaque tokens as a (future) extension? The client asks for one specifically, and the AS (if it wants) provides a token that's guaranteed to be human-readable.

[fimbault]

This has appeared again in the terminology PR #155

Proposal for access token : "a data artifact representing a set of delegated access rights, the format of which is opaque to the client software." The last part of the sentence is a requirement, so should be included in the main text, not in the definition.

[Denisthemalice]

Access tokens should not considered to be opaque. Let us also suppose that an end-user wishes to use an identifier specific to a RS because he does not want RSs to link accesses on different RSs. Let us suppose that an organization implements an AS that conforms to GNAP. If access tokens were considered to be opaque, that organization could insert, in addition to the locally unique identifier, a globally unique identifier inside the access token and clients would not be allowed to detect it. So it is a matter of trust towards the AS by the client to behave correctly. Clients need to be able to control the content of the access token to make sure it only contains what has been requested and no more. If the content is not satisfactory, then the client will discard the access token. It is also interesting for the client to control that the access token is well-formed before being communicated to the RS.

It would be wise to introduce a version number inside the access token to identify its version and allow changes in its structure for the future.

[fimbault]

@Denisthemalice in theory the risk you mention exists. But there have been several arguments against the idea. It seems unlikely that we'd move towards implementing non-opaque tokens as a general scheme. The question really is whether we have valid reasons to support it as an optional/extension feature, as suggested by Yaron. If so, we'll probably need some text to get a concrete proposal.

[Denisthemalice]

As far as I understand, the protocol between the client and the AS returns, for the access token, a data structure and not a blob. If it were a blob, we would still need some kind of version identifier so that the RS can interpret the content of the blob. Originally, in OAuth, a RS was supposed to have a strong relationship with one AS. In GNAP, I believe that an AS can deliver an access token to a RS with which he has no prior relationship. So there is not necessarily a prior agreement about the structure of the access token between the RS and an AS. The AS may publish the version(s) of the access token it supports. In the same way, the RS may publish the version(s) of the access token it supports. Then the client would be able to select a version in the intersection of these versions (if any).

Allowing the client to inspect the access token is a matter of trust in the system. Transparency is an important privacy principle. Without transparency, there is no trust by the clients and hence by the end-users.

So it is not a matter of risk as you say, but a matter of trust or confidence.

[fimbault]

Yes I agree it's linked to the trust model. Currently it is generally assumed that the AS is trusted, although we might indeed want to relax some of that within GNAP in the future.

[Denisthemalice]

It is not a matter of "relaxing trust". Trust is not black and white.

It is important to recall what means trust: degree to which a user or other stakeholder has confidence that a product or system will behave as intended See ISO/IEC 25010:2011(en), 4.1.3.2

It is of particular importance that users (and auditors) can have confidence that the AS behaves as intended. Without access token transparency, they can't.

[fimbault]

Ok we all agree on the fact that there should be assurance as to how the system behaves. I'm not totally sure the proposed solution is absolutely necessary for that (there are other ways to build confidence, such as product certification for instance / other people want to put the AS on their own phone / etc.). If you want to put that issue forward, the proposed way would be to submit text for an extension and gather consensus from the WG (knowing that current cases are based on opaque tokens, which are here to stay and provide some benefits).

[Denisthemalice]

Product certification provides confidence at the time of the audit, but not later on Token transparency provides confidence in real time to any client. This makes a big difference.

For the time being an AS is a server. Until a secure element is used as an AS in a phone, that case does not exist.

It is not a matter of "an extension". Nothing would prevent a client to ignore the content of an access token if it wishes to do so. But those clients that wish to inspect the content of the access token should be prevented to do it.

Both philosophies can co-exist, without using any "extension".

[fimbault]

what I mean by extension is relative to GNAP core, which is probably going to be based on opaque tokens, at least until we can review what the alternative implies.

[Denisthemalice]

Let us explore some implications.

As indicated above, this topic is related whether or not an access token can be issued to a RS with which an AS has no prior relationship.

With opaque tokens, a prior relationship is mandatory. This is adequate for closed environments only. With non-opaque tokens, there is no need for a prior relationship. This allows scalability over the whole Internet.

There are also some side effects:

In the former case, the AS will be able to know and spy where the token it issues is likely to be delivered. In the later case, it is even possible in some cases to hide to the AS the identity of the RS.

Let us wait and see what other people which are not in the same time zone think about these arguments.

[fimbault]

Handling opaque tokens would require additional text, not sure how that would work.
I propose that we put in the text a requirement that tokens must be non opaque tokens (what is currently known to be working well), to be reviewed later on if as @yaronf suggested we find a reason and a way to cover both cases.

See also issue #169 which advocates for the possibility of various token mechanisms, which is much easier to do if tokens are considered opaque. Would it mean we need to specify their type somewhere?

[jricher]

@fimbault I think you have that backwards -- current text is that all tokens are assumed to be opaque and handling non-opaque tokens would require additional text.

[fimbault]

I need to check but I remember I removed a definition where it was explicit. Maybe it's already somewhere else already, in that case indeed no change is needed.

[jricher]

No we pulled it out of the definition of tokens that they're opaque to the client software, and that needs to be added back in. But what's "known to be working well" is opaque tokens, and I was saying your comment above was inverted from what you meant, I think. :)

[fimbault]

yes sorry :-)

[yaronf]

This thread is getting too long... I think the Terminology section is not the right place to mandate technical properties. I thought we already found a more appropriate section to include this text.

Re: the actual question, @Denisthemalice explained why he needs non-opaque tokens, hence my question whether those can be a future extension.

[agropper]

Is it not the case that attenuated delegation requires non-opaque tokens? See also #169.

[fimbault]

As Justin pointed out rightly, I wrote my comment too fast, sorry. And so it wasn't clear, especially for delegated tokens which are a bit special.

Delegated tokens are opaque to the protocol in general, you just can pass them around. But they wouldn't be opaque to the client that wants to execute attenuation. So to clarify what I meant : I think opaque tokens, which wouldn't make it mandatory for the client to understand the format unless there's a very good reason for them to do so, is a better assumption. But there might still be the need to know which token we're dealing with (like an optional type. Or a type that defaults to jwt but can be changed. Or maybe not even necessary as the format type is distinguishable with a bit of additional parsing - except of course if encrypted... ).

Hopefully this is a bit more clear (note that it's just an idea at this stage). We might need to be careful about security issues because of type optionality though... (and so in the short term, opaque tokens are good as we know what to expect, the rest is need text). The need expressed by Denis is a bit different.

[Denisthemalice]

The new current definition of an access token is now:

Access Token a data artifact representing a set of rights and/or attributes. Note: an access token can be first issued to an client instance (requiring authorization by the RO) and subsequently rotated.

The Note should be removed since in some cases, an authorization by the RO is necessary (i.e. when rights are being used) while in some other cases, it is unnecessary (i.e. when attributes are being used). Another argument is that this Note does not explain a facet of the definition but only one of the many usages of the access token.

I agree with fimbault : we wouldn't make it mandatory for the clients to understand the detailed format unless there's a very good reason for them to do so, Such a good reason is confidence if the system (e.g. inspection of the content of the access token).

However, when an AS supports more than one access token format, a client should be able to request an access token compliant with a given format supported by the RS. In any case, access tokens formats should be advertised by the AS, so that the client can verify whether there is a match with the access token formats supported by the RS.

The AS Discovery function which is supported by sending an HTTP OPTIONS request to the grant request endpoint from an AS to retrieve the server's discovery information should be able to return the supported access token formats.

The same should apply for a RS Discovery function.

[fimbault]

The note refers to the interaction with the RO. This happens before any token is issued.

Supposing we include that functionality: the token format could just be a parameter in the request (access_token_types), discovery could return the access_token_types_supported.

[agropper]

Please confirm compatibility with a capabilities model.

• The RO client may get one or more capabilities from the RS anonymously (pays in cash)
• Some of the capabilities could be subject to filtering to reduce privileges.
• Some capabilities could be directed to an auditor that would have to participate in the access transaction.
• The RO may pass one or more capabilities along with some private policies to a GNAP AS.
• The RO may pass one or more capabilities to an auditor role.
• The AS consumes and processes requests based on RO policy to issue (filtered capabilities) as access tokens.
• The RO does not have to be accessible when the GNAP AS processes some requests (based on policy, of course).
• The access tokens are capable of further filtered delegation outside the control of AS or RS.
• When finally processed at the RS, an audit trail can be constructed as promised in the original RO / RS contract.

Adrian

[fimbault]

I don't think you can get all of that for all types of tokens (hence the need for multiple formats / depending on the needs). Ex:

• JWT can't be filtered once issued
• but auditing ocaps is more complex (see for instance zcap handling abuse)
• might have some security and privacy considerations

Then we're supposed to be agnostic to the content, but depending on what's effectively contained, it might not fit a capabilities model. Ex from Denis: roles/groups (instead of actions), which are geared towards a role or attribute based access.

(I'm not suggesting what we should do, just stating what can be done)

[agropper]

It seems obvious that the RS holds all the power in every instance. Some of that power is shared with the RO in a GNAP-compatible way. Capabilities need not be the only GNAP-compatible option but I hope we can have an example of how at least one capability model is used in an audit-capable way.

ROs need audit-ability in order to hold delegates, including the RS and AS, to account.

Adrian

On Fri, Mar 12, 2021 at 8:16 AM Fabien @.***> wrote:

I don't think you can get all of that for all types of tokens (hence the need for multiple formats / depending on the needs). Ex:

• JWT can't be filtered once issued
• but auditing ocaps is more complex (see for instance zcap handling abuse https://w3c-ccg.github.io/zcap-ld/#handling-abuse)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-797483343, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YMIBM4Y3KYHNXASHTLTDIH2ZANCNFSM4UZKIFUA .

[fimbault]

It depends what you want to audit:

• For pure ocaps, auditing policies is fine but auditing access is complex. See zlcap and Horton.
• for ACL, RBAC, ABAC, implementing auditing access is straighforward. It's also possible to audit dynamic policies but that requires a bit more tooling generally (ex; NIST NGAC, casbin, OPA) (to my knowledge)

[agropper]

I’m primarily looking to make GNAP’s role in zero-trust architecture (ZTA) as obvious as practical.

I use the term policies exclusively as those things the RO controls that it is willing to share with the GNAP AS and nobody else.

I look for auditability to be an option that introduces another party, for example a notary and a log they create, that can be used to document the outcome of a GNAP-protected access.

The audit log could document what client requested access at the AS or received access to the RS. I do not consider this an audit of policies themselves but rather the outcome of applying the policies.

Auditability is very different from audit. Audit can be very costly and involve disclosure of policies and contracts that have nothing to do with GNAP.

In ZTA terms, I’m hoping for a way to keep both the RS and the AS honest by introducing the option for a transaction log kept by the notary.

Adrian

On Fri, Mar 12, 2021 at 8:44 AM Fabien @.***> wrote:

It depends what you want to audit:

• For pure ocaps, auditing policies is fine but auditing access is complex. See zlcap and Horton http://www.erights.org/elib/capability/horton/.
• for ACL, RBAC, ABAC, implementing access control audits is straighforward. It's also possible to audit dynamic policies (ex; NIST NCAG, OPA)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-797498882, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YNEPFTXSH4C3AL7P5DTDILE5ANCNFSM4UZKIFUA .

[fimbault]

Not sure, but my 2 cents.

We discussed in the past the idea of a separate Interact Server (IS), which is a functional role in the AS (but that could be separated physically) dedicated to managing the interactions (so, what accesses are requested by the client to the AS). You might log those decisions.

If that IS is managed by the RS (or a gateway to the RSs), then it could potentially extend its log facility to what the client really requested, but that becomes a very specific deployment scenario (ex: monitor your own services). A general purpose solution seems hard to achieve for that second part of the need.

Note: currently there's no IS in the spec. That could be an optional component (I made a MVP a few months ago, works fine).

[agropper]

A compromised RS or AS can’t be trusted to keep accurate logs but we need to do the best we can. On the RS side, we can encourage contemporaneous write-only access to an external log. On the AS side, we can ensure that an honest RS logs the action of the AS as much as the RO is willing to have be transparent for audit purposes.

I believe this is the most common case. Two parties to a contract, the RO and RS as client and service provider respectively, choose to introduce a notary as a third party that keeps a log.

Adrian

On Fri, Mar 12, 2021 at 9:39 AM Fabien @.***> wrote:

Not sure, but my 2 cents.

We discussed in the past the idea of a separate Interact Server (IS), which is a functional role in the AS (but that could be separated physically) dedicated to managing the interactions (so, what is requested by the client). You might log those decisions.

If that IS is managed by the RS (or a gateway to the RS), then it could potentially extend its log facility to what client really requested, but that becomes a specific deployment scenario.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-797530638, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YMGOSNO7L3VKCONK5DTDIRTNANCNFSM4UZKIFUA .

[jricher]

Access tokens will continue to be opaque to the client instance. Both structured/formatted tokens an unstructured tokens need to be supported by the core protocol.

The format and data model of the access token must be known to AS, and the access token must be able to be interpreted by the RS. However, none of these requirements lead to the client instance needing to know what is inside the token itself and there are significant privacy and security issues with the client instance needing to know the structure and content of the token. Interoperability between the AS and RS in terms of token formats could be addressed in a separate extension document, akin to UMA2's Federated Authorization https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0.html

See #114 for separating the RS-facing protocol from the core.

[agropper]

@jricher Are you saying that GNAP clients cannot support filtering capabilities they receive from an AS?

[jricher]

A GNAP client instance will not have insight into the access token itself. The AS will be able to tell the client what it claims the token is good for using the access field in the response, but this is sent alongside the token itself. Ultimately, the RS needs to decide if the token is any good. The client will not be able to split the token or attenuate the token itself, these are functions of the AS. The client will be able to get an attenuated token through the grant management API and/or the token refresh API, though this will result in a new token.

[agropper]

That's interesting and should be made clear. It means, for example that an AS that grants a token to the doctor will need to be involved if the doctor wants to delegate that token to a staff member with lesser privileges. If this is GNAP's decision, we should explain why (for example efficiency or auditability).

From a privacy perspective, we can try to respect the privacy interests of both the subject and the end-user (where end-user here means the actor that presents a token (maybe /the/ token) to the RS. The privacy interest of the subject is not at issue here. Having their AS involved in any attenuation attempt gives them more power, not less. However, the privacy interest of the requesting party (the actor that presents claims to the AS) might be better served if they had the ability to attenuate as well as delegate.

On Wed, Mar 17, 2021 at 12:40 PM Justin Richer @.***> wrote:

A GNAP client instance will not have insight into the access token itself. The AS will be able to tell the client what it claims the token is good for using the access field in the response, but this is sent alongside the token itself. Ultimately, the RS needs to decide if the token is any good. The client will not be able to split the token or attenuate the token itself, these are functions of the AS. The client will be able to get an attenuated token through the grant management API and/or the token refresh API, though this will result in a new token.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-801234853, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YIRVMQM7G4XTH5QU7DTEDLPJANCNFSM4UZKIFUA .

[Denisthemalice]

@jricher; You wrote:

The AS will be able to tell the client what it claims the token is good for using the access field in the response, but this is sent alongside the token itself.

With such a sentence, the client and therefore the end-user cannot be confident in the access token that has been produced. Using the access field in the response, the AS might, for example, voluntarily omit to mention that the email address from the end-user has been placed into the access token whereas it would indeed be present into the access token. An end-user should be able to consent about the privileges that are being included into an access token and then after should be able to verify that these privileges and NO MORE have effectively been placed into the AS.

The client can filter the access token with a coarse granularity: it can either accept to send it to the RS as a whole or it can refuse to sent it to the RS.

Since we want to have design that takes care of the end-user privacy, an access token issued by a GNAP AS cannot be opaque.

[Denisthemalice]

A typo in the following sentence:

An end-user should be able to consent about the privileges hat are being included into an access token and then after should be able to verify that these privileges and NO MORE have effectively been placed into the AS.

I was meaning:

An end-user should be able to consent about the privileges that are being included into an access token and then after should be able to verify that these privileges and NO MORE have effectively been placed into the access token .

[jricher]

@Denisthemalice Since the AS creates the token, it is fully and finally responsible for what goes "into" the access token. The client can only request, the AS declares the result.

[Denisthemalice]

@jricher;

If you want to have a design based on "Spy by design" then you are right, since the end-user will not know whether, for example, his email address has been included or not into the access token. If it is included, it allows the RSs to link their user accounts and other servers that use that email address to also link their user accounts with the RSs that receive that email address.

If you want to have a design that takes care of the end-user privacy, then you have no choice: the access token MUST NOT be opaque to the client.

[jricher]

@Denisthemalice the access token could always be used by the RS to look up information about the user, which can include private information, so making the token non-opaque doesn't help. Your proposal also eliminates the ability to have by-reference access tokens that contain :no: information at all. This is the most used pattern in privacy preserving systems today. Furthermore, your proposal would leak information to the client instance. As a user, I don't want my client to know things like my email address or account information if it doesn't have to.

What you're describing is best situated as privacy considerations for the AS implementation, and as part of the design of an RS-facing portion of the protocol space as discussed in #114. None of these require the access token to be non-opaque to the client, and in fact there are many documented disadvantages to doing so.

[Denisthemalice]

@jricher . You wrote:

the access token could always be used by the RS to look up information about the user, which can include private information, so making the token non-opaque doesn't help.

As soon as an RS would be doing a Token Introspection call to the AS, the client will be ignorant whether the AS includes or not in its response, by example, an email address. A Token Introspection call to the AS made by the RS would be another component of a design based on "Spy by design" .

You also wrote:

Furthermore, your proposal would leak information to the client instance.

If the end-user does not trust his client, it should not use it. The end-user trusts its client to behave as expected. I already mentioned that the draft should describe upfront the trust relationships and such a section is still currently missing.
See "Trust relationships" Issue #214

You also wrote:

What you're describing is best situated as privacy considerations for the AS implementation,

This has little to do with privacy considerations for the AS implementation. The AS should be prevented, as far as possible, to act as "Big Brother". This has to do with privacy considerations for the end-user (and hence client) and for the RS.

• The end-user (and hence the client) should be able to know which private attributes are being communicated by the AS to the RS, and the most important is that the end-user should be able to consent to the communication of these private attributes and also should be informed of the reasons to communicate them.
• The RS should not implement nor use Token Introspection. In general, any call back from a RS to an AS should be avoided.

As I already said:

Transparency is an important privacy principle. Without transparency, there is no trust by the clients and hence by the end-users.

[jricher]

The AS and RS are related in this model. You are proposing a drastically different trust model, and not one that the working group has expressed interest in pursuing.

[Denisthemalice]

The trust relationships between the AS and the RS are currently undefined in the draft, as well as the trust relationships with the other components of the model. See the issue "Trust relationships"" #214.

In this issue 214, I have proposed text for a new section to address the trust relationships. I would guess that you will have some objections with some sentences. It is the time to discuss about them. I invite you to reply and to propose your amendments if any. At this time, you have not yet participated to the debate around the issue #214.

By experience, it is premature to design a protocol if the trust relationships are left undefined. It is also impossible to correctly address privacy properties after the design of the protocols unless ending with a "Spy by design" architecture where the end-user consent and the user notices are ignored.

It is unfortunate, that the cart has been placed before the horse.

[agropper]

@Denisthemalice The trust model is indeed critical and a centerpiece of my privacy-driven comments in GNAP. Trust is coercive to the individual resource owner in the sense that a shrink-wrap license, or being forced to sign a HIPAA Privacy Practices Notice before getting care at a hospital is coercive to the sick and anxious person.

The GNAP trust model gives the RO as much power as possible in any particular use-case including, for example. US HIPAA and EU GDPR. The instrument of RO's power is control over the GNAP AS. That control can be self-sovereign if the AS is compiled from source and self-hosted or it can be based on a fiduciary relationship to the AS operator. GNAP need not be concerned with the fiduciary distinction and can reasonably assume that all ASs are self-sovereign to their owners.

Core aspects of RO power are delegation, automation, learning, and data minimization. Delegation enables the RO to hire experts as fiduciaries. Automation enables the RO to delegate to a semi-autonomous agent. Learning enables the RO and their agent adapt better and faster than the other actors in a use-case. Data minimization is one way that the RO and their agent protect their learning advantage and avoid surveillance by others, discrimination, or censorship.

Surveillance is essential to the exercise of power. Ideally, the RO and their agent would have total information awareness (to use a Snowden-era term) but this is impractical in some use cases and may be illegal in law enforcement use cases such as No-fly lists.

A "Spy by design" architecture with the GNAP AS as the combined consent and surveillance actor is what I hope we're working toward. Giving other actors in the protocol the opportunity to contact the AS or the RO directly is desirable from this surveillance perspective as long as the power to avoid or minimize that leakage of information (the AS or RO service endpoint) such as through the introduction of pseudonyms and mediators under the RO's control.

[fimbault]

@agropper interesting input

[alanhkarp]

Tokens are not opaque to the client in SPKI, zcap-ld, Orie's implementation with VCs, or our Zebra Copy work. That feature allows useful operations.

• A client can delegate a sub-scope token to a process it runs. For example, a renderer could be given only read permission even though the client has read/write.
• The RO may delegate tokens to its own AS that delegates them based on the user's policy.
• Delegation can be done off-line. The US Navy liked this feature for battlefield scenarios with uncertain connectivity. For example, a token issued by an on-shore AS might need to be delegated while a ship at sea is radio silent.
• The client may want to verify that the token has only the specified scopes.

These benefits must be weighed against the advantages spelled out in this thread. The biggest to my mind is the encapsulation that enables the issuing AS to change what's in a token without coordinating with anyone else. Unfortunately, that precludes the RO from using its own AS for delegation of its tokens.

I think some benefits mentioned on this thread are less of an issue. Privacy matters with non-opaque tokens can be handled by encrypting specific fields or by tokenizing those fields as done with credit card transactions. Issuing tokens to one-off private keys preserves responsibility tracking while preventing unintended correlations.

As an aside, the procedure specified in the Horton paper is more complicated than needed here. Horton is doing responsibility tracking solely with object references in a programming language. The necessary information can be encoded in a privacy preserving way directly into the tokens we're discussing.

[jricher]

@alanhkarp I completely disagree with this model. I think those benefits can be reached with the existing GNAP model, though in slightly different ways. Take the offline delegation for example -- why would the AS for the ship be on-shore? The ship would have its own AS close to the RS's. That ship's AS can take, as input, signals from on-short systems when available and make local decisions when not available.

Additionally, much of the benefits of what's being described as a "token" in the above is not a good match for the "access token" in the current model. This is why I keep saying that things like zcap and VC's fit into two potential places:

• as inputs to the AS during its delegation process; this is where I see the most application to what's proposed here
• as token formats for the RS (not client) to consume; this is where the confusion comes in, as now it's tempting to push more expectations onto the client where they do not belong

Fundamentally, the client instance is the entity being delegated to, nothing else. The AS manages the delegation, and it does so on behalf of the RS when an RS exists (remember, we have identity use cases where there is no RS).

[agropper]

I'm not understanding the disagreement between @alanhkarp and @jricher and have not seen this Horton paper but I'm starting to see where @jricher and I could reach consensus.

GNAP could design around each major actor having their own GNAP AS in the sense that a zero-trust architecture draws a trust boundary around a resource and its policy enforcement point. So, for example,

• the RS (processor role) would have a GNAP AS it specifies and trusts, call it AS-RS,
• the RO (subject role) would have a GNAP AS it specifies and trusts, call it AS-RO,
• the RQ (delegate role) might have an AS of their own too but that seems far outside the GNAP protocol concerns.

As a result, when:

• the RO is interacting with the RS, they might actually be dealing with the AS-RS
• the RQ is interacting with the RS, they might be dealing with the AS-RS
• the RQ is interacting with the RO, they are dealing with the AS-RO
• the RS is interacting with the RO because they are presented with a token, they are dealing with the AS-RO
• the RS or RQ "need" to deal with the live RO rather than an agent they might have a way to bypass the AS-RO

Notice that I've avoided using the word "client" and that there could be many different kinds of identifiers, capabilities, and tokens compatible with this model.