Re: [Txauth] RS/AS communication for multiparty cases

[Fabien Imbault <[e-mail]>]

Thanks Denis. It clarifies what you have in mind.

While I agree with the general idea that we need to take privacy more
seriously, there are a few hypotheses that we need to put in perspective :
1) AS-RS relationship <=> big brother. It may happen as we all know, but
you always have the choice as a user to not deal with orgs you don't like
or maybe even take action if they don't respect the law.
2) the collusion possibility (Alice's uncle) : there are of course
situations where that may be an issue. This is I guess the reason for the
sovrin foundation to require that only approved issuers can participate.
But even if you open up the system, it always ends up as whether you can
trust the uncle to be honest in the first place (knowing that trust is a
social construct). So I may require the issuer to be a well known
participant instead.
3) The use of hardware FIDO inspired components does relax some of the
previous concern, but comes with its own sets of challenges. Biometrics
come with their own sets of potential issues. More trivially, if you loose
your hardware, you loose your ID. And there can also be hacks in hardware.
If I find a way to import or export the private key from the enclave, the
system fails.

So in the end, I agree it's best to enable as much privacy by design as we
possibly can, but we need to put that in perspective with use cases too and
make some tradeoffs. Healthcare in particular is a domain that is concerned
with a constant balance between privacy and security, and sometimes there
is no possibility to tick all boxes.
I think an UMA2/OpenId Heart scenario is a very important case to consider
in that respect.

Fabien




On Fri, Jul 3, 2020 at 12:01 PM Denis <[e-mail]> wrote:

> Hello Fabien,
>
> In 2017, I made a presentation at the OAuth workshop in Zurich.
>
> The paper is available from:
> https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacy-by-design-eID-scheme-supporting-Attribute-based-Access-Control.pdf
>
> The slides are available from:
> https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacybydesign.ppt
> *Note*: The slides should be viewed "full screen" to get the animations.
>
> The general approach is how to construct from scratch a "privacy by
> design" architecture taking also into consideration "security by design".
>
> Coming back to your requirement, I would not cover it if it infringes the
> sentence "the RS and the AS never communicate directly".
>
> You should start your design by defining the trust relationships, then
> apply the privacy requirements while not forgetting the security
> requirements.
>
> Denis
>
> Hello Denis,
>
> I have been following your comments. I still fail to see the global
> privacy preserving architecture you're proposing. It would help to get a
> more thorough proposal if you can.
>
> But more specifically, I have a comment on :
>
> "I would have preferred that you meant: the RS and the AS never
> communicate directly, which is indeed a nice property to follow
> to ensure the user's privacy."
>
> I think that may come as an issue in some cases, especially for multiparty patterns (like in UMA). Typically we may wish the RS to start a grant request and use the handle to continue until a token is generated.
>
> I think those cases, which weren't initially covered by OAuth2, are very important to cover as well. How would you cover such requirements?
>
> Fabien
>
>
>
>