Subject: [Txauth] Three Client-Server use cases with several ASs built along "Privacy by Design" (PbD)

From: Denis <[email-masked]>
Date: Tue, 4 Aug 2020 11:07:48 +0200

I tried my best twice to download three use cases in the Use cases 
directory, but I failed.

Rather than failing a third time, here is the direct link of the second try:

    https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD)

Denis

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 10 Aug 2020 15:26:47 +0200

Thanks Denis for that proposal.

I believe we can already implement most of your idea with
https://github.com/ietf-wg-gnap/general/wiki/Modular-Interaction-Server. In
particular, we can easily provide an interaction server that is chosen by
the Client (which might be operated by the Client itself for instance, or
by a party distinct from the AS). But for now, I'm still going through the
AS, who knows what the tokens are used for. Your use case has the ability
to change that.

So, I'm trying to figure out how 6.2 would work, regarding RS hiding and
the need for non opaque tokens.

You're saying : "The choice of hiding or not hiding the true name of the RS
is a choice made by the Client. Such a choice may be handled through a
local configuration of the Client. If "privacy by default" is applied,
hiding the true name of the RS should be the default choice.
The role of the AS is to deliver the requested types of attributes into an
access token without necessarily knowing to which RS(s) the access token is
intended."

So, after the interaction with the RO, suppose we get a list of tokens to
mint (for instance in the format defined in XYZ), in this case we expect to
generate token1:

"token1": [
        {
            "actions": [
                "read"
            ],
            "locations": [
                "https://server.example.net/"
            ],
            "datatypes": [
                "metadata",
                "images"
            ]
        }
    ],

As per rfc7523, the AS would then mint a JWT access token, including "aud":"
https://server.example.net".
Later the RS can check that the token has been generated with the right
audience (amongst other things).
Note that there's a proposal to provide more guidance on that topic
https://github.com/ietf-wg-gnap/general/wiki/Directed-Access-Tokens. We can
imagine it can soon become fairly complex.

If I understand you well, you're suggesting an additional layer of
indirection, in the form of alias to the locations url?
Something in the form of:
1) The Client contacts the RS for information
2) The RS responds to the Client (including one-off aliases and their time
to live)
3) The Client deals with consent (cf proposal related to the IS component),
and the AS doesn't have to know what is asked
4) Based on what the RO consented, the AS is asked to mint token1, token2,
etc. with aliases
5) The Client uses the aliased tokens with the RS

I see the reason why you're suggesting that, but implementing that at scale
may be tricky. I don't see how a local configuration of the client (as you
suggest) is enough, you'll also need to share that information with the RS
at some point. To work, the mapping between the Client and the RS would
have to be private and probably even transient (if we can to avoid AS from
scrawling RS endpoints for durable aliases, which would defeat the
purpose), which pose questions of cache invalidation and the
synchronicity with the token itself.

Also you're saying (before step 5 occurs): "Once the Client has obtained
the requested access tokens, they are not immediately presented to the RS:
the Client should be able to verify that the content of each access token
is in accordance with each access token request."
I don't see the reason why the AS would present something else, especially
if it has no notion what is actually requested to whom (if the previous
scheme is effective). If we suppose we're asking for read access, maybe it
could try a write access too, but for what use?
The suggested verification scheme on the Client side supposes that the
Client is honest anyway. If so, the Client would only use the token for a
read request, so I don't understand which threat we're trying to avoid
(except from something theorical). If the Client is dishonest, it won't
care anyway.

Am I over complexifying what you have in mind?

Fabien

On Tue, Aug 4, 2020 at 11:08 AM Denis <[email-masked]> wrote:

> --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Francis Pouatcha <[email-masked]>
Date: Mon, 10 Aug 2020 23:58:20 -0400

Hello Denis,

what you describe in the use case seems to be the default behavior of the
protocol. Let me map it with this abstract protocol flow:

+-----------+      +--------------+  +-----------+  +----+
 +---------------------+
| Requestor |      | Orchestrator |  | RS        |  | GS |  | Resource
Controller |
| is UNIV-1 |      |  is UNIV-1   |  | is UNIV-0 |  | or |  |         is
      |
|   Staff   |      | Registr. App |  | Server    |  | AS |  |
 Student       |
+-----------+      +--------------+  +-----------+  +----+
 +---------------------+
  |(1) RegisterStudent    |                |           |                |
  |---------------------->|                |           |                |
  |                       |(2) RequestRecordIntent(RecordType,StudentId,
  |                       |
 OrchestratorId):AuthRequest[RecordType,StudentId]
  |                       |<-------------->|           |                |
  |                       |                |           |                |
  |                       |(3)
AuthZRequest(RecordType,StudentId,OrchestratorId)
  |                       |--------------------------->|                |
  |                       |                |           |(4)
ConsentRequest(RecordType,
  |                       |                |           |
 OrchestratorId):Consent
  |                       |                |           |<-------------->|
  |                       |(5) AuthZ[RecordType,StudentId,OrchestratorId]
  |                       |<---------------------------|                |
  |                       |                |           |                |
  |                       |(2)
RequestRecord(RecordType,StudentId,OrchestratorId)
  |                       |     :RecordOf[StudentId]   |                |
  |                       |<-------------->|           |                |
  |(7) Registered         |                |           |                |
  |<----------------------|                |           |                |
  +                       +                +           +                +

we assume the authz request sent by "Client" to "AS" describes the
protected resource without referring to the authz server. An AS can issue
the authz to release the graduation record  of a student
((5) AuthZ[RecordType,StudentId,OrchestratorId]), without any reference to
the target university.

What matters for this authz object is:
- StudentId: a reference to the student as known to the resource server.
- RecordType: a reference to a resource of type graduation record as
understandable  by the resource server.
- OrchestratorId: reference to the Orchestrator. Can be used to bind authz
to Orchestrator.

But:
- RS must trust AS issued token.
- StudentId must be known to RS, AS and Orchestrator.

Therefore, the AS does not need to know the RS. Keep the audience field
empty.

Same principle applies for the second use case.

What privacy problem do you see here?

Best regards.
/Francis

-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/

---

From: Fabien Imbault <[email-masked]>
Date: Tue, 11 Aug 2020 08:17:14 +0200

Hi Francis,

I think Denis points to the fact that, in the current situation, the AS
receives the resource request from the Client and therefore knows what
tokens are asked. Then it also implements the consent interface (and
possibly the login too) and so it also knows who validates and what is
accepted or not.

I don't think the abstract flow deals with those privacy concerns.

Then I agree with you on the audience field of the token, if left empty it
simplifies part of the problem, although it removes a big part of the
control you may want from directed tokens. That's why I'm willing to better
develop the RS hiding idea.

Fabien

Le mar. 11 août 2020 à 05:58, Francis Pouatcha <fpo=
[email-masked]> a écrit :

> TXAuth mailing list
> [email-masked]

---

From: Francis Pouatcha <[email-masked]>
Date: Tue, 11 Aug 2020 17:27:03 -0400

Hello Fabian,

On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault <[email-masked]>
wrote:

> tokens are asked.
The token request must not mention any reference of the RS.

> Then it also implements the consent interface (and possibly the login too)
> and so it also knows who validates and what is accepted or not.
>
Decoupling this does not change the privacy context, as the AS issues the
Token. AS needs to add a reference to the RC in the token. SO AS can
correlate on StudentId anyway.

> I don't think the abstract flow deals with those privacy concerns.
To solve the privacy problem addressed in this thread, we need to go the
(SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to issue a VC
(Verifiable Credential) to the Student (in his role of RC). The Student
will then present this claim to UNIV-1 during his registration. In this
case we need no Grant negotiation and no AS.

Best regards.
/Francis

>> - OrchestratorId: reference to the Orchestrator. Can be used to bind
>> authz to Orchestrator.
>>
>> But:

---

From: Tom Jones <[email-masked]>
Date: Tue, 11 Aug 2020 15:27:13 -0700

"The token request must not mention any reference of the RS."
this cannot be an absolute rule. I have cases were the client needs to tell
the user which they are coming back for additional grants.
The reason is typically because a request by the client for data/access
from the rs was rejected. The reason for the rejection is important for the
client to make the case to the user for additional permissions.
Peace ..tom

On Tue, Aug 11, 2020 at 2:27 PM Francis Pouatcha <fpo=
[email-masked]> wrote:

>> Then it also implements the consent interface (and possibly the login
>> too) and so it also knows who validates and what is accepted or not.
>>
>> Then I agree with you on the audience field of the token, if left empty
>> it simplifies part of the problem, although it removes a big part of the
>>> what you describe in the use case seems to be the default behavior of
>>> the protocol. Let me map it with this abstract protocol flow:
>>>
>>> | is UNIV-1 |      |  is UNIV-1   |  | is UNIV-0 |  | or |  |
>>>  is          |

---

From: Francis Pouatcha <[email-masked]>
Date: Tue, 11 Aug 2020 18:40:04 -0400

On Tue, Aug 11, 2020 at 6:27 PM Tom Jones <[email-masked]>
wrote:

> this cannot be an absolute rule. I have cases were the client needs to
> tell the user which they are coming back for additional grants.
- If you want privacy, *don't* expose RS identity to AS.
- If you want transparency, expose RS identity to AS.
You can't have both....
/Francis

>>>>   |                       |<-------------->|           |
>>>>   |                       |                |
>>>>  |<-------------->|
>>>>  |(5) AuthZ[RecordType,StudentId,OrchestratorId]
>>>>   |                       |<-------------->|           |
>>>>   |(7) Registered         |                |           |
>>>>   +                       +                +           +
>>>> +
>>>> authz to Orchestrator..

---

From: Tom Jones <[email-masked]>
Date: Tue, 11 Aug 2020 15:42:47 -0700

I guess I need to ask the group as a whole then.
Will GNAP support self-issued Identifiers?
If so then the AS is on the user's device.
I need to understand that SII are in-scope.
Peace ..tom

On Tue, Aug 11, 2020 at 3:40 PM Francis Pouatcha <[email-masked]> wrote:

>>> Decoupling this does not change the privacy context, as the AS issues
>>> the Token. AS needs to add a reference to the RC in the token. SO AS can
>>>>> RequestRecordIntent(RecordType,StudentId,
>>>>>   |                       |
>>>>> Therefore, the AS does not need to know the RS. Keep the audience
>>>>> field empty.
>>>>>

---

From: Francis Pouatcha <[email-masked]>
Date: Tue, 11 Aug 2020 18:47:25 -0400

Hello Tom,

> I need to understand that SII are in-scope.
I hope GNAP will be designed to support SII. If you could drop some use
cases here: https://github.com/ietf-wg-gnap/general/wiki

>>>> On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault <
>>>> [email-masked]> wrote:
>>>>
>>>>> Hi Francis,
>>>>>
>>>>> I think Denis points to the fact that, in the current situation, the
>>>>> AS receives the resource request from the Client and therefore knows what
>>>>> tokens are asked.
>>>>>
>>>> To solve the privacy problem addressed in this thread, we need to go
>>>> the (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to issue a
>>>> VC (Verifiable Credential) to the Student (in his role of RC). The Student
>>>>> Then I agree with you on the audience field of the token, if left
>>>>> empty it simplifies part of the problem, although it removes a big part of
>>>>> the control you may want from directed tokens. That's why I'm willing to
>>>>> better develop the RS hiding idea.
>>>>>
>>>>> Fabien
>>>>>
>>>>>> | Requestor |      | Orchestrator |  | RS        |  | GS |  |
>>>>>> Resource Controller |

---

From: Dick Hardt <[email-masked]>
Date: Tue, 11 Aug 2020 16:29:08 -0700

Tom, do you have a straw man on how a client would interact with an AS on
the user's device?
ᐧ

On Tue, Aug 11, 2020 at 3:43 PM Tom Jones <[email-masked]>
wrote:

>> You can't have both.....

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 12 Aug 2020 10:02:01 +0200

Hi Francis,

My comments are embedded into your email with FI.

You're saying in a follow-up message:
"- If you want privacy, *don't* expose RS identity to AS.
- If you want transparency, expose RS identity to AS.
You can't have both...."
While that may seem a reasonable dichotomy at first sight, I believe the
reality is actually more nuanced and depends on how we end up designing the
system.

Cheers,
Fabien

> The token request must not mention any reference of the RS.

FI : yes we can do that, but as Tom commented, it's not a general rule. And
for instance in XYZ you do describe the URL of the resource. See also the
use case on directed tokens, which is an interesting topic which makes
sense in many scenarios.
But as soon as you include that possibility, it's fair to think that this
capability could be used for surveillance purposes in some cases, unless
you found a privacy by design scheme that applies by default.
Again this doesn't mean that transparency requirements aren't important
too, but I think there are other ways it can be achieved (for instance, an
inspiration is the certificate transparency project). Could be an extension
to the protocol I believe.

> correlate on StudentId anyway.

FI : I disagree. It does change the privacy context, if as Denis suggested,
the consent is made outside of the AS and if you don't send to the AS the
information on the RS when it needs to issue the token.
Correlation on StudentId is limited as long as it's a local identifier,
i.e. not a public DID.

As a concrete example: a user may want to use an application to access
rs_domain/directory1 and rs_domain/directory2 in read and write, which are
managed by a RO.
What I suggested is that the Client may (optionally) carry out its consent
through a decoupled IS server (separated from the AS), that displays the UI
based on the RS requirements => the IS knows what information is used, but
the IS may be chosen by the IS independently from the AS or even run by the
Client itself.
In this case, suppose the RO only provided consent for rs_domain/directory1
for read.
We now need to get back to the AS to mint the access token.

If we want the AS to not know about the RS, we either :
- don't supply the rs_domain at all -> the JWT says that directory1 in read
access is authorized. The downside is that we actually cannot control to
which URL the authorization applies. In that case I agree with your either
or statement.
- or find a way to hide it (not sure if that's practical, hence my
questions on RS hiding). This would have the benefit of still allowing
directed tokens -> the JWT says that rs_petname/directory1 in read access
is authorized.

Either way, the AS has not been provided any information as to where this
token will effectively be used.

> case we need no Grant negotiation and no AS.

FI : That may be useful but it's not enough. What you describe only works
because you take a very specific use case, aka registration. This fits well
into DID/VC without requiring authorization per say. However grant
negotiation is still required for more general settings of authorization.
I've added a DID example to my implementation, will publish it soon.

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 12 Aug 2020 10:21:53 +0200

+1 on support for SSI, which I believe the charter includes (e.g. "Verified
Credentials").
Maybe not in the core (?) but at least as an extension.

Also interested in how you imagine the AS on the user's device, which I
believe is yet a separated topic from SSI (even is that could be an
enabler).

Cheers,
Fabien

On Wed, Aug 12, 2020 at 12:47 AM Francis Pouatcha <[email-masked]> wrote:

>>>>>>> what you describe in the use case seems to be the default behavior
>>>>>>> of the protocol. Let me map it with this abstract protocol flow:
>>>>>>>

---

From: Francis Pouatcha <[email-masked]>
Date: Wed, 12 Aug 2020 07:51:43 -0400

Hello Fabian, inline

On Wed, Aug 12, 2020 at 4:02 AM Fabien Imbault <[email-masked]>
wrote:

> FI : yes we can do that, but as Tom commented, it's not a general rule.
> And for instance in XYZ you do describe the URL of the resource. See also
> the use case on directed tokens, which is an interesting topic which makes
> sense in many scenarios.
>
Yes. But disclosing the protected resource discloses the RS.

> you found a privacy by design scheme that applies by default.
Yes. THen default shall be using URI of resource description and not URL to
indicate resource location.

> to the protocol I believe.
The certificate transparency deals with something else. Does not fit in
this context at all.

> FI : I disagree. It does change the privacy context, if as Denis
> suggested, the consent is made outside of the AS and if you don't send to
> the AS the information on the RS when it needs to issue the token.
How local can the StudentId be? It is known to both universities and to the
AS. Without a public reference, you can not link information between
unrelated entities (AS, UNIV-0 and UNIV-1). Using VCs can help here. Then
you do not need central AS anymore.

> the IS may be chosen by the IS independently from the AS or even run by the
What do you need an AS for? Then it can sign the claim to present to RS.

> In this case, suppose the RO only provided consent for
> rs_domain/directory1 for read.
If AS mint access token, AS will be able to correlate. Unless start
applying intransparent complex reference mapping techniques, wich might
even open room for new attack vectors.

> - don't supply the rs_domain at all -> the JWT says that directory1 in
> read access is authorized. The downside is that we actually cannot control
> to which URL the authorization applies. In that case I agree with your
> either or statement.
>
Yes

> directed tokens -> the JWT says that rs_petname/directory1 in read access
More complexity.

> negotiation is still required for more general settings of authorization.
Please drop the next use case in the repo, so we can dive deeper into it
and see how to provide both central grant negotiation and privacy.

Francis Pouatcha

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 12 Aug 2020 14:12:17 +0200

Inline too :-)

> Yes. But disclosing the protected resource discloses the RS.

FI : yes of course. Which is why RS hiding may be a solution.

> Yes. THen default shall be using URI of resource description and not URL
> to indicate resource location.
>

FI : yes

> The certificate transparency deals with something else. Does not fit in
FI : It does, and has already been implemented by some projects in
relationship with OAuth2, as an additional component.

> How local can the StudentId be? It is known to both universities and to
> the AS. Without a public reference, you can not link information between

FI : see keri or peer DID for instance, as examples of local ID.
Again SSI/DID/VC doesn't mean you don't need AS, those technologies can be
complementary.

>> What I suggested is that the Client may (optionally) carry out its
>> consent through a decoupled IS server (separated from the AS), that
>> displays the UI based on the RS requirements => the IS knows what
>> information is used, but the IS may be chosen by the IS independently from
>> the AS or even run by the Client itself.
>>

FI : to be sure, what is "it"?

> even open room for new attack vectors.

FI : not necessarily with respect to correlation, see above.
As for mapping techniques, this is the very reason of my question to Denis.

>> directed tokens -> the JWT says that rs_petname/directory1 in read access

FI : yes

> and see how to provide both central grant negotiation and privacy.

FI : will do.

---

From: Denis <[email-masked]>
Date: Wed, 12 Aug 2020 15:23:56 +0200

With so many messages in the last 24 hours, I can't respond to all of 
them at once.
I picked the last one first.

> Inline too :-)
>
> On Wed, Aug 12, 2020 at 1:51 PM Francis Pouatcha <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hello Fabian, inline
>
>     On Wed, Aug 12, 2020 at 4:02 AM Fabien Imbault
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hi Francis,
>
>         While that may seem a reasonable dichotomy at first sight, I
>         believe the reality is actually more nuanced and depends on
>         how we end up designing the system.
>
[Denis] This is in fact more nuanced. It is possible to prevent the AS 
to know who the RS is by hiding the true identifier of the RS to the AS.

This means that for security reasons the access token is still targeted 
but that the field included into the access token will look like a 
random number to the RS.
That random number will change for every access token.

In order for the RS to make sure that the access token is indeed 
intended for itself, it will need to combine the field included into the 
access token
with an unsigned field external to the access token.

This would have a major consequence for the structure of a GNAP access 
token that will be rather different from an OAuth 2.0 access token.
It should have two parts : a signed part and an unsigned part.

>
>         Cheers,
>         Fabien
>
>         On Tue, Aug 11, 2020 at 11:27 PM Francis Pouatcha
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>             Hello Fabian,
>
>             On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>                 Hi Francis,
>
>                 I think Denis points to the fact that, in the current
>                 situation, the AS receives the resource request from
>                 the Client and therefore knows what tokens are asked.
>
>         FI : yes we can do that, but as Tom commented, it's not a
>         general rule. And for instance in XYZ you do describe the URL
>         of the resource. See also the use case on directed tokens,
>         which is an interesting topic which makes sense in many
>         scenarios.
>
>         But as soon as you include that possibility, it's fair to
>         think that this capability could be used for surveillance
>         purposes in some cases, unless you found a privacy by design
>         scheme that applies by default.
>
>     Yes. THen default shall be using URI of resource description and
>     not URL to indicate resource location.
>
>
> FI : yes
>
>
>         Again this doesn't mean that transparency requirements aren't
>         important too, but I think there are other ways it can be
>         achieved (for instance, an inspiration is the certificate
>         transparency project). Could be an extension to the protocol I
>         believe.
>
>     The certificate transparency deals with something else. Does not
>     fit in this context at all.
>
>                 Then it also implements the consent interface (and
>                 possibly the login too) and so it also knows who
>                 validates and what is accepted or not.
>
>             Decoupling this does not change the privacy context, as
>             the AS issues the Token. AS needs to add a reference to
>             the RC in the token. SO AS can correlate on StudentId anyway.
>
>
>         FI : I disagree. It does change the privacy context, if as
>         Denis suggested, the consent is made outside of the AS and if
>         you don't send to the AS the information on the RS when it
>         needs to issue the token.
>         Correlation on StudentId is limited as long as it's a local
>         identifier, i.e. not a public DID.
>
>     How local can the StudentId be? It is known to both universities
>     and to the AS. Without a public reference, you can not link
>     information between unrelated entities (AS, UNIV-0 and UNIV-1).
>     Using VCs can help here. Then you do not need central AS anymore.
>
>
> Again SSI/DID/VC doesn't mean you don't need AS, those technologies 
> can be complementary.
>
>
>         As a concrete example: a user may want to use an application
>         to access rs_domain/directory1 and rs_domain/directory2 in
>         read and write, which are managed by a RO.
>         What I suggested is that the Client may (optionally) carry out
>         its consent through a decoupled IS server (separated from the
>         AS), that displays the UI based on the RS requirements => the
>         IS knows what information is used, but the IS may be chosen by
>         the IS independently from the AS or even run by the Client
>         itself.
>
>     If AS mint access token, AS will be able to correlate. Unless
>     start applying intransparent complex reference mapping techniques,
>     wich might even open room for new attack vectors.
>
>
>         - don't supply the rs_domain at all -> the JWT says that
>         directory1 in read access is authorized. The downside is that
>         we actually cannot control to which URL the
>         authorization applies. In that case I agree with your either
>         or statement.
>
>     Yes
>
>         - or find a way to hide it (not sure if that's practical,
>         hence my questions on RS hiding). This would have the benefit
>         of still allowing directed tokens -> the JWT says that
>         rs_petname/directory1 in read access is authorized.
>
>     More complexity.
>
>
> FI : yes

[Denis] As indicated at the top of this email, it is possible to always 
hide the identifier of the RS while still targetting every access token.

BTW, I have expanded the notion of targetting by allowing to place into 
a target field of an access token either or both a RS identifier and
a Service Name (SN) identifier to which the RS belongs.

Two targetting fields should hence be possible: a RS identifier and a SN 
identifier.

This is also a difference with an OAuth 2.0 access token.

>         Either way, the AS has not been provided any information as to
>         where this token will effectively be used.
>
>
>
>             To solve the privacy problem addressed in this thread, we
>             need to go the (SSI/DiD/VC) way. Then UNIV-0 (in his role
>             of RS) will have to issue a VC (Verifiable Credential) to
>             the Student (in his role of RC). The Student will then
>             present this claim to UNIV-1 during his registration. In
>             this case we need no Grant negotiation and no AS.
>
[Denis] This is a complete redesign of my example and hence this 
redesign has no relationship with my example.

>
>         FI : That may be useful but it's not enough. What you describe
>         only works because you take a very specific use case, aka
>         registration. This fits well into DID/VC without requiring
>         authorization per say. However grant negotiation is still
>         required for more general settings of authorization.
>
>     Please drop the next use case in the repo, so we can dive deeper
>     into it and see how to provide both central grant negotiation and
>     privacy.
>
>
> FI : will do.
>
>
>                 Then I agree with you on the audience field of the
>                 token, if left empty it simplifies part of the
>                 problem, although it removes a big part of the control
>                 you may want from directed tokens. That's why I'm
>                 willing to better develop the RS hiding idea.
>
>                 Fabien
>
>                 Le mar. 11 août 2020 à 05:58, Francis Pouatcha
>                 <fpo=[email-masked]
>                 <mailto:[email-masked]>> a écrit :
>
>                     Hello Denis,
>
>                     what you describe in the use case seems to be the
>                     default behavior of the protocol. Let me map it
>                     with this abstract protocol flow:
>
[Denis] The redesign below has no relationship with my use case.

A key element of my design is the User, i.e. a physical person which 
initiates the exchanges. In the example below the User has disappeared.

A User is not a role, but an entity.

BTW, I can't understand the role of an "Orchestrator" (which is left 
undefined).

>
>                     +-----------+     +--------------+  +-----------+
>                      +----+  +---------------------+
>                     | Requestor |      | Orchestrator |  | RS        |
>                      | GS |  | Resource Controller |
>                     | is UNIV-1 |      |  is UNIV-1  |  | is UNIV-0 | 
>                     | or |  |        is          |
>                     |  Staff   |      | Registr. App |  | Server    | 
>                     | AS |  |    Student       |
>                     +-----------+ +--------------+  +-----------+
>                      +----+  +---------------------+
>                       |(1) RegisterStudent    |             |         
>                      |           |
>                      |(4) ConsentRequest(RecordType,
>                       |                    |       |           |
>                      OrchestratorId):Consent
>                       |                    |       |  |<-------------->|
>                       |(7) Registered         |             |         
>                       +                       +             +         
>                      +           +
>                     we assume the authz request sent by "Client" to
>                     "AS" describes the protected resource without
>                     referring to the authz server. An AS can issue the
>                     authz to release the graduation record of a
>                     student
>                     ((5) AuthZ[RecordType,StudentId,OrchestratorId]),
>                     without any reference to the target university.
>
>                     - RecordType: a reference to a resource of type
>                     graduation record as understandable  by the
>                     resource server.
>                     - OrchestratorId: reference to the Orchestrator.
>                     Can be used to bind authz to Orchestrator.
>
>                     But:
>                     Therefore, the AS does not need to know the RS.
>                     Keep the audience field empty.
>
[Denis] The User, a physical person which initiates the exchanges has 
disappeared.
No more user, no more privacy issues ? :-)

Denis

>
>                     Best regards.
>                     /Francis
>
>                     On Tue, Aug 4, 2020 at 5:08 AM Denis
>                     <[email-masked] <mailto:[email-masked]>>
>                     wrote:
>
>                         I tried my best twice to download three use
>                         cases in the Use cases directory, but I failed.
>

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 12 Aug 2020 16:13:05 +0200

Thanks Denis.

A few questions to clarify:
- "the field included into the access token will look like a random number
to the RS." - you mean AS?
- "It should have two parts : a signed part and an unsigned part." -
Something like an authenticated cipher (e.g. AES-GCM) + a KV mapping (with
short expiry) between the temporary_id and the url, on the RS side?

Then the algorithm would be :
1. Client contacts the RS, which sends a resource description (temporary_id)
2. The flow continues and a token is generated, using the temporary_id
3. Client makes the call to the RS, using the token. The RS verifies the
signature + it also verifies that the mapping is the one expected.

BTW, it makes the RS decide the maximum token expiry.
The issue is that it requires more work on the RS side, compared to a
stateless JWT.

Is that correct?

Fabien

On Wed, Aug 12, 2020 at 3:24 PM Denis <[email-masked]> wrote:

> With so many messages in the last 24 hours, I can't respond to all of them
> at once.
>> [Denis] This is in fact more nuanced. It is possible to prevent the AS to
> know who the RS is by hiding the true identifier of the RS to the AS.
>
> but that the field included into the access token will look like a random
> number to the RS.
> In order for the RS to make sure that the access token is indeed intended
> for itself, it will need to combine the field included into the access
> token
> BTW, I have expanded the notion of targetting by allowing to place into a
> target field of an access token either or both a RS identifier and
>>> FI : That may be useful but it's not enough. What you describe only
>>> works because you take a very specific use case, aka registration. This
>>> fits well into DID/VC without requiring authorization per say. However
>>> grant negotiation is still required for more general settings of
>>> authorization.
>>>

---

From: Denis <[email-masked]>
Date: Wed, 12 Aug 2020 16:34:49 +0200

Hi  Fabien,
> - "the field included into the access token will look like a random 
> number to the RS." - you mean AS?

Correct. This was a typo.

> Something like an authenticated cipher (e.g. AES-GCM) + a KV mapping 
> (with short expiry) between the temporary_id and the url, on the RS side?

Sorry, I am not aware of this scheme.

> 1. Client contacts the RS, which sends a resource description 

No. It is not a temporary_id.

> 2. The flow continues and a token is generated, using the temporary_id.

No. Knowing the true identifier of the RS, the Client picks a 
random_number and computes a concealed_target_identifier =  hash 
(random_number, RS_identifier).

While requesting an access token, the Client asks the AS to include the 
concealed_target_identifier into the access token.

While sending the access token, the Client adds the random_number into 
the unsigned part of the access token.

While receiving the access token, the RS uses it own RS_identifier and 
retrieves the random_number placed into the unsigned part of the access 
token.
It then computes a hash of (random_number, RS_identifier). If the result 
matches with the concealed_target_identifier placed into the signed part of
the access token, then the access token is well targeted, otherwise it 
is ignored.

> 3. Client makes the call to the RS, using the token. The RS verifies 
> the signature + it also verifies that the mapping is the one expected.
>

Token expiration is unrelated.

> The issue is that it requires more work on the RS side, compared to a 

Adding two computations using a one way hash function is not a big deal.

>  Is that correct?

No. The mechanism is fairly different. It has already been explained 
once on the OAuth mailing list.

Denis

>
> Fabien
>
>
> On Wed, Aug 12, 2020 at 3:24 PM Denis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     With so many messages in the last 24 hours, I can't respond to all
>     of them at once.
>>             While that may seem a reasonable dichotomy at first
>>             sight, I believe the reality is actually more nuanced and
>>             depends on how we end up designing the system.
>>
>     [Denis] This is in fact more nuanced. It is possible to prevent
>     the AS to know who the RS is by hiding the true identifier of the
>     RS to the AS.
>
>     This means that for security reasons the access token is still
>     targeted but that the field included into the access token will
>     look like a random number to the RS.
>     intended for itself, it will need to combine the field included
>     into the access token
>     This would have a major consequence for the structure of a GNAP
>     access token that will be rather different from an OAuth 2.0
>     access token.
>>                     I think Denis points to the fact that, in the
>>                     current situation, the AS receives the resource
>>                     request from the Client and therefore knows what
>>                     tokens are asked.
>>
>>             general rule. And for instance in XYZ you do describe the
>>             URL of the resource. See also the use case on directed
>>             tokens, which is an interesting topic which makes sense
>>             in many scenarios.
>>
>>             purposes in some cases, unless you found a privacy by
>>             design scheme that applies by default.
>>
>>         Yes. THen default shall be using URI of resource description
>>         and not URL to indicate resource location.
>>
>>
>>     FI : yes
>>
>>
>>             Again this doesn't mean that transparency requirements
>>             aren't important too, but I think there are other ways it
>>             can be achieved (for instance, an inspiration is the
>>             certificate transparency project). Could be an extension
>>         The certificate transparency deals with something else. Does
>>         not fit in this context at all.
>>
>>     FI : It does, and has already been implemented by some projects
>>     in relationship with OAuth2, as an additional component.
>>
>>
>>                     Then it also implements the consent interface
>>                     (and possibly the login too) and so it also knows
>>                     who validates and what is accepted or not.
>>
>>                 Decoupling this does not change the privacy context,
>>                 as the AS issues the Token. AS needs to add a
>>                 reference to the RC in the token. SO AS can correlate
>>                 on StudentId anyway.
>>
>>
>>             FI : I disagree. It does change the privacy context, if
>>             as Denis suggested, the consent is made outside of the AS
>>             and if you don't send to the AS the information on the RS
>>             when it needs to issue the token.
>>             Correlation on StudentId is limited as long as it's a
>>             local identifier, i.e. not a public DID.
>>
>>         How local can the StudentId be? It is known to both
>>         universities and to the AS. Without a public reference, you
>>         can not link information between unrelated entities (AS,
>>         UNIV-0 and UNIV-1). Using VCs can help here. Then you do not
>>         need central AS anymore.
>>
>>
>>     Again SSI/DID/VC doesn't mean you don't need AS, those
>>     technologies can be complementary.
>>
>>
>>             As a concrete example: a user may want to use an
>>             application to access rs_domain/directory1 and
>>             rs_domain/directory2 in read and write, which are managed
>>             by a RO.
>>             What I suggested is that the Client may (optionally)
>>             carry out its consent through a decoupled IS server
>>             (separated from the AS), that displays the UI based on
>>             the RS requirements => the IS knows what information is
>>             used, but the IS may be chosen by the IS independently
>>             from the AS or even run by the Client itself.
>>
>>         start applying intransparent complex reference mapping
>>         techniques, wich might even open room for new attack vectors.
>>
>>
>>             directory1 in read access is authorized. The downside is
>>             that we actually cannot control to which URL the
>>             authorization applies. In that case I agree with your
>>             either or statement.
>>
>>         Yes
>>
>>             hence my questions on RS hiding). This would have the
>>             benefit of still allowing directed tokens -> the JWT says
>>             that rs_petname/directory1 in read access is authorized.
>>
>>         More complexity.
>>
>>
>>     FI : yes
>
>     [Denis] As indicated at the top of this email, it is possible to
>     always hide the identifier of the RS while still targetting every
>     access token.
>
>     BTW, I have expanded the notion of targetting by allowing to place
>     into a target field of an access token either or both a RS
>     identifier and
>     Two targetting fields should hence be possible: a RS identifier
>     and a SN identifier.
>
>>             Either way, the AS has not been provided any information
>>             as to where this token will effectively be used.
>>
>>
>>
>>                 To solve the privacy problem addressed in this
>>                 thread, we need to go the (SSI/DiD/VC) way. Then
>>                 UNIV-0 (in his role of RS) will have to issue a VC
>>                 (Verifiable Credential) to the Student (in his role
>>                 of RC). The Student will then present this claim to
>>                 UNIV-1 during his registration. In this case we need
>>                 no Grant negotiation and no AS.
>>
>>             FI : That may be useful but it's not enough. What you
>>             describe only works because you take a very specific use
>>             case, aka registration. This fits well into DID/VC
>>             without requiring authorization per say. However grant
>>         Please drop the next use case in the repo, so we can dive
>>         deeper into it and see how to provide both central grant
>>         negotiation and privacy.
>>
>>
>>     FI : will do.
>>
>>
>>                     Then I agree with you on the audience field of
>>                     the token, if left empty it simplifies part of
>>                     the problem, although it removes a big part of
>>                     the control you may want from directed tokens.
>>                     That's why I'm willing to better develop the RS
>>                     hiding idea.
>>
>>                     Fabien
>>
>>                         what you describe in the use case seems to be
>>                         the default behavior of the protocol. Let me
>>                         map it with this abstract protocol flow:
>>
>     A key element of my design is the User, i.e. a physical person
>     which initiates the exchanges. In the example below the User has
>     disappeared.
>
>     BTW, I can't understand the role of an "Orchestrator" (which is
>     left undefined).
>
>>
>>                         +-----------+     +--------------+
>>                          +-----------+  +----+  +---------------------+
>>                         | Requestor |      | Orchestrator |  | RS   
>>                             |  | GS |  | Resource Controller |
>>                         | is UNIV-1 |      | is UNIV-1   |  | is
>>                         UNIV-0 |  | or |  |        is          |
>>                         |  Staff   |      | Registr. App |  | Server 
>>                           |  | AS | |       Student  |
>>                         |    | |           |  OrchestratorId):Consent
>>                         |    | |  |<-------------->|
>>                           |
>>                         we assume the authz request sent by "Client"
>>                         to "AS" describes the protected resource
>>                         without referring to the authz server. An AS
>>                         can issue the authz to release the graduation
>>                         record  of a student
>>                         - RecordType: a reference to a resource of
>>                         type graduation record as understandable  by
>>                         the resource server.
>>                         - OrchestratorId: reference to the
>>                         Orchestrator. Can be used to bind authz to
>>                         Orchestrator.
>>
>>                         But:
>>                         Therefore, the AS does not need to know the
>>                         RS. Keep the audience field empty.
>>
>     [Denis] The User, a physical person which initiates the exchanges
>     has disappeared.
>>                         <[email-masked]
>>                         <mailto:[email-masked]>> wrote:
>>
>>                             I tried my best twice to download three
>>                             use cases in the Use cases directory, but
>>                             I failed.
>>
>     [email-masked] <mailto:[email-masked]>

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 12 Aug 2020 16:38:07 +0200

Thanks that's clear now.
Then it's not a signature, it's just a hash.

Thanks
Fabien

On Wed, Aug 12, 2020 at 4:35 PM Denis <[email-masked]> wrote:

> While sending the access token, the Client adds the random_number into the
> unsigned part of the access token.
>
> the access token, then the access token is well targeted, otherwise it is
> ignored.
>
> No. The mechanism is fairly different. It has already been explained once
> on the OAuth mailing list.
>
> Denis
>
>
> Fabien
>
>
>>>> While that may seem a reasonable dichotomy at first sight, I believe
>>>> the reality is actually more nuanced and depends on how we end up designing
>>>> the system.
>>>>
>>> But as soon as you include that possibility, it's fair to think that
>>>> this capability could be used for surveillance purposes in some cases,
>>>> unless you found a privacy by design scheme that applies by default.
>>>>
>> Again SSI/DID/VC doesn't mean you don't need AS, those technologies can
>> be complementary.
>>
>>
>>>

---

From: Justin Richer <[email-masked]>
Date: Wed, 12 Aug 2020 12:07:37 -0400

Hi Denis,

I think this is a fascinating approach that can allow for privacy-preservation in the way that you’re after. Here’s how I would see it fitting into GNAP:

When the client makes the request, it includes the concealed_target_identifer in the resources request, probably in lieu of any kind of “location” field. The semantics of this field could be defined in GNAP core or in a short extension describing the reusable field in the “resources” request:

resources: [
   “action": [“read”],
   “concealed_target_identifier”: “876tghjkjasdf7234f”
]

At that point, it’s up to the AS to bind that identifier to the resulting access token and make that information available to the RS. That could happen by packing it into a JWT, which is likely the format you’d want for this kind of thing because an introspection call from the RS would identify the RS to the AS. 

The missing piece is a way for the client to present the random number to the RS alongside the access token. I think this would make sense as a separate HTTP header defined in that extension. So the client would get back its token and send this to the RS:

Authorization: GNAP eyj0…
Target-Identifier-Random-Number: ABE54298411...

The RS would look at the token, find the hashed value within, and use the value in the secondary header to recalculate and verify the hash on the request. All of this can be done without the RS calling the AS and without the client divulging the RS’s location or identity to the AS.

 — Justin

> On Aug 12, 2020, at 10:34 AM, Denis <[email-masked]> wrote:
> 
> Hi  Fabien,
>> Thanks Denis.
>> 
>> - "the field included into the access token will look like a random number to the RS." - you mean AS?
>> - "It should have two parts : a signed part and an unsigned part." - Something like an authenticated cipher (e.g. AES-GCM) + a KV mapping (with short expiry) between the temporary_id and the url, on the RS side?
> No. Knowing the true identifier of the RS, the Client picks a random_number and computes a concealed_target_identifier =  hash (random_number, RS_identifier).
> 
> While requesting an access token, the Client asks the AS to include the concealed_target_identifier into the access token.
> 
> While sending the access token, the Client adds the random_number into the unsigned part of the access token.
> 
> While receiving the access token, the RS uses it own RS_identifier and retrieves the random_number placed into the unsigned part of the access token.
> It then computes a hash of (random_number, RS_identifier). If the result matches with the concealed_target_identifier placed into the signed part of 
> the access token, then the access token is well targeted, otherwise it is ignored.
> 
>> 3. Client makes the call to the RS, using the token. The RS verifies the signature + it also verifies that the mapping is the one expected.  
>> 
>> The issue is that it requires more work on the RS side, compared to a stateless JWT. 
> No. The mechanism is fairly different. It has already been explained once on the OAuth mailing list.
> 
> Denis
> 
>> 
>> Fabien
>> 
>> 
>> On Wed, Aug 12, 2020 at 3:24 PM Denis <[email-masked] <mailto:[email-masked]>> wrote:
>> With so many messages in the last 24 hours, I can't respond to all of them at once.
>>> On Wed, Aug 12, 2020 at 1:51 PM Francis Pouatcha <[email-masked] <mailto:[email-masked]>> wrote:
>>> Hello Fabian, inline
>>> 
>>> On Wed, Aug 12, 2020 at 4:02 AM Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
>>> Hi Francis, 
>>> 
>>> "- If you want privacy, don't expose RS identity to AS.
>>> While that may seem a reasonable dichotomy at first sight, I believe the reality is actually more nuanced and depends on how we end up designing the system. 
>> [Denis] This is in fact more nuanced. It is possible to prevent the AS to know who the RS is by hiding the true identifier of the RS to the AS.
>> 
>> This means that for security reasons the access token is still targeted but that the field included into the access token will look like a random number to the RS.
>> In order for the RS to make sure that the access token is indeed intended for itself, it will need to combine the field included into the access token 
>> This would have a major consequence for the structure of a GNAP access token that will be rather different from an OAuth 2.0 access token. 
>>> On Tue, Aug 11, 2020 at 11:27 PM Francis Pouatcha <[email-masked] <mailto:[email-masked]>> wrote:
>>> Hello Fabian,
>>> 
>>> On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
>>> Hi Francis,
>>> 
>>> I think Denis points to the fact that, in the current situation, the AS receives the resource request from the Client and therefore knows what tokens are asked.
>>> FI : yes we can do that, but as Tom commented, it's not a general rule. And for instance in XYZ you do describe the URL of the resource. See also the use case on directed tokens, which is an interesting topic which makes sense in many scenarios.  
>>> But as soon as you include that possibility, it's fair to think that this capability could be used for surveillance purposes in some cases, unless you found a privacy by design scheme that applies by default. 
>>> Yes. THen default shall be using URI of resource description and not URL to indicate resource location. 
>>> 
>>> FI : yes 
>>> 
>>> Again this doesn't mean that transparency requirements aren't important too, but I think there are other ways it can be achieved (for instance, an inspiration is the certificate transparency project). Could be an extension to the protocol I believe. 
>>> The certificate transparency deals with something else. Does not fit in this context at all.
>>>  
>>> FI : It does, and has already been implemented by some projects in relationship with OAuth2, as an additional component. 
>>> 
>>>  
>>> Then it also implements the consent interface (and possibly the login too) and so it also knows who validates and what is accepted or not.
>>> Decoupling this does not change the privacy context, as the AS issues the Token. AS needs to add a reference to the RC in the token. SO AS can correlate on StudentId anyway.
>>> 
>>> FI : I disagree. It does change the privacy context, if as Denis suggested, the consent is made outside of the AS and if you don't send to the AS the information on the RS when it needs to issue the token.
>>> Correlation on StudentId is limited as long as it's a local identifier, i.e. not a public DID. 
>>> How local can the StudentId be? It is known to both universities and to the AS. Without a public reference, you can not link information between unrelated entities (AS, UNIV-0 and UNIV-1). Using VCs can help here. Then you do not need central AS anymore.
>>> 
>>> Again SSI/DID/VC doesn't mean you don't need AS, those technologies can be complementary. 
>>>  
>>> 
>>> As a concrete example: a user may want to use an application to access rs_domain/directory1 and rs_domain/directory2 in read and write, which are managed by a RO. 
>>> What I suggested is that the Client may (optionally) carry out its consent through a decoupled IS server (separated from the AS), that displays the UI based on the RS requirements => the IS knows what information is used, but the IS may be chosen by the IS independently from the AS or even run by the Client itself. 
>>> In this case, suppose the RO only provided consent for rs_domain/directory1 for read. 
>>> If AS mint access token, AS will be able to correlate. Unless start applying intransparent complex reference mapping techniques, wich might even open room for new attack vectors.
>>> 
>>> - don't supply the rs_domain at all -> the JWT says that directory1 in read access is authorized. The downside is that we actually cannot control to which URL the authorization applies. In that case I agree with your either or statement.  
>>> Yes 
>>> - or find a way to hide it (not sure if that's practical, hence my questions on RS hiding). This would have the benefit of still allowing directed tokens -> the JWT says that rs_petname/directory1 in read access is authorized.
>>> More complexity. 
>>> 
>>> FI : yes
>> [Denis] As indicated at the top of this email, it is possible to always hide the identifier of the RS while still targetting every access token.
>> 
>> BTW, I have expanded the notion of targetting by allowing to place into a target field of an access token either or both a RS identifier and 
>> Two targetting fields should hence be possible: a RS identifier and a SN identifier.
>> 
>>> Either way, the AS has not been provided any information as to where this token will effectively be used.  
>>> 
>>> 
>>> To solve the privacy problem addressed in this thread, we need to go the (SSI/DiD/VC) way. Then UNIV-0 (in his role of RS) will have to issue a VC (Verifiable Credential) to the Student (in his role of RC). The Student will then present this claim to UNIV-1 during his registration. In this case we need no Grant negotiation and no AS.
>> [Denis] This is a complete redesign of my example and hence this redesign has no relationship with my example.
>> 
>>> 
>>> FI : That may be useful but it's not enough. What you describe only works because you take a very specific use case, aka registration. This fits well into DID/VC without requiring authorization per say. However grant negotiation is still required for more general settings of authorization.  
>>> Please drop the next use case in the repo, so we can dive deeper into it and see how to provide both central grant negotiation and privacy.
>>> 
>>> FI : will do. 
>>> 
>>> Then I agree with you on the audience field of the token, if left empty it simplifies part of the problem, although it removes a big part of the control you may want from directed tokens. That's why I'm willing to better develop the RS hiding idea. 
>>> 
>>> Fabien 
>>> 
>>> Le mar. 11 août 2020 à 05:58, Francis Pouatcha <fpo=[email-masked] <mailto:[email-masked]>> a écrit :
>>> Hello Denis,
>>> 
>>> what you describe in the use case seems to be the default behavior of the protocol. Let me map it with this abstract protocol flow:
>> A key element of my design is the User, i.e. a physical person which initiates the exchanges. In the example below the User has disappeared.
>> 
>> BTW, I can't understand the role of an "Orchestrator" (which is left undefined). 
>> 
>>> 
>>> +-----------+      +--------------+  +-----------+  +----+  +---------------------+
>>> | Requestor |      | Orchestrator |  | RS        |  | GS |  | Resource Controller |
>>> | is UNIV-1 |      |  is UNIV-1   |  | is UNIV-0 |  | or |  |         is          |
>>> |   Staff   |      | Registr. App |  | Server    |  | AS |  |       Student       |
>>> +-----------+      +--------------+  +-----------+  +----+  +---------------------+
>>>   |                       |     OrchestratorId):AuthRequest[RecordType,StudentId]
>>>   |                       |<-------------->|           |                |
>>>   |                       |                |           |                |
>>>   |                       |(3) AuthZRequest(RecordType,StudentId,OrchestratorId)
>>>   |                       |                |           |(4) ConsentRequest(RecordType,
>>>   |                       |(2) RequestRecord(RecordType,StudentId,OrchestratorId)
>>> we assume the authz request sent by "Client" to "AS" describes the protected resource without referring to the authz server. An AS can issue the authz to release the graduation record  of a student ((5) AuthZ[RecordType,StudentId,OrchestratorId]), without any reference to the target university. 
>>> 
>>> - RecordType: a reference to a resource of type graduation record as understandable  by the resource server.
>>> - OrchestratorId: reference to the Orchestrator. Can be used to bind authz to Orchestrator.
>>> 
>>> But:
>>> Therefore, the AS does not need to know the RS. Keep the audience field empty.
>>> 
>> [Denis] The User, a physical person which initiates the exchanges has disappeared. 
>>> On Tue, Aug 4, 2020 at 5:08 AM Denis <[email-masked] <mailto:[email-masked]>> wrote:
>>> I tried my best twice to download three use cases in the Use cases directory, but I failed.
>>> 
>>> https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD) <https://github.com/ietf-wg-gnap/general/wiki/Three-Client-Server-use-cases-with-several-ASs-built-along-%22Privacy-by-Design%22-(PbD)>
>>> Denis
>>> 
>>> 
>>> 
>>> -- 
>>> Francis Pouatcha
>>> https://adorsys-platform.de/solutions/ <https://adorsys-platform.de/solutions/>
>> -- 
>> TXAuth mailing list
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> 
> -- 
> TXAuth mailing list
> [email-masked]

---

From: Francis Pouatcha <[email-masked]>
Date: Wed, 12 Aug 2020 12:39:45 -0400

+1 for temporary_id. Solves the privacy issue, but requires Step (2).

---

From: Francis Pouatcha <[email-masked]>
Date: Wed, 12 Aug 2020 12:52:10 -0400

+1 for this approach.
On Wed, Aug 12, 2020 at 12:07 PM Justin Richer <[email-masked]> wrote:

> Hi Denis,
>
> I think this is a fascinating approach that can allow for
> privacy-preservation in the way that you’re after. Here’s how I would see
> it fitting into GNAP:
>
> When the client makes the request, it includes the
> concealed_target_identifer in the resources request, probably in lieu of
> any kind of “location” field. The semantics of this field could be defined
> in GNAP core or in a short extension describing the reusable field in the
> “resources” request:
>
> resources: [
>    “action": [“read”],
concealed_target_identifier is either provided by server in step (2) or
computed by client using a property unique to the RS (location-url) and a
nonce (Target-Identifier-Random-Number).

> At that point, it’s up to the AS to bind that identifier to the resulting
> access token and make that information available to the RS. That could
> happen by packing it into a JWT, which is likely the format you’d want for
> this kind of thing because an introspection call from the RS would identify
> the RS to the AS.
>
> The missing piece is a way for the client to present the random number to
> the RS alongside the access token. I think this would make sense as a
> separate HTTP header defined in that extension. So the client would get
> back its token and send this to the RS:
>
Nonce is added to the request header to allow RS to validate the target of
the authz token.

/Francis

>
>
> The RS would look at the token, find the hashed value within, and use the
> value in the secondary header to recalculate and verify the hash on the
> request. All of this can be done without the RS calling the AS and without
> the client divulging the RS’s location or identity to the AS.
>
>  — Justin
>
>