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

[Denis <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hello Fabian, inline
>
>     On Wed, Aug 12, 2020 at 4:02 AM Fabien Imbault
>     <[e-mail] <mailto:[e-mail]>> wrote:
>
>         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.
>
[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
>         <[e-mail] <mailto:[e-mail]>> wrote:
>
>             Hello Fabian,
>
>             On Tue, Aug 11, 2020 at 2:17 AM Fabien Imbault
>             <[e-mail]
>             <mailto:[e-mail]>> 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.
>
>             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.
>
>     Yes. But disclosing the protected resource discloses the RS.
>
>
> FI : yes of course. Which is why RS hiding may be a solution.
>
>
>         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.
>
>
> 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.
>
>
>         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.
>
>     What do you need an AS for? Then it can sign the claim to present
>     to RS.
>
>
> FI : to be sure, what is "it"?
>
>         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 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.
>
>
> FI : not necessarily with respect to correlation, see above.
> As for mapping techniques, this is the very reason of my question to 
> Denis.
>
>
>
>         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.
>
>     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.
>
>
>
>                 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.
>
[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.
>
>
>         I've added a DID example to my implementation, will publish it
>         soon.
>
>             Best regards.
>             /Francis
>
>
>                 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=[e-mail]
>                 <mailto:[e-mail]>> 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    |             |         
>                      |           |
>                     |---------------------->|               |         
>                      |             |
>                       |                       |(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?
>
[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
>                     <[e-mail] <mailto:[e-mail]>>
>                     wrote:
>
>                         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
>
>
>     -- 
>     Francis Pouatcha
>     Co-Founder and Technical Lead
>     adorsys GmbH & Co. KG
>     https://adorsys-platform.de/solutions/
>