Subject: [GNAP] About the use case called "Self sovereign identity (SSI)"

From: Denis <[email-masked]>
Date: Fri, 21 Aug 2020 14:48:12 +0200

Hello Francis,

This WG has not been formed to address SSI (Self sovereign identity). 
This use case can be solved without using an AS and a RS
and without using a "Self Sovereign Identity (SSI)" approach.

-Alice visits the website of AC-Tickets.

-Alice looks up and finds "Bamberg Symphony", the concert she wants to 
attend.

-Alice is informed that she can get a discount price if she is a 
resident of Bamberg.

-Alice fills a form and enters the requested information.
  She indicates that she is a resident of Bamberg and so she gets the 
discounted price.

-Alice makes the payment using 3D secure.

-Alice gets back a QR code on her phone that will be scanned when 
entering the concert hall.

-Alice goes to the concert at Bamberg Symphony.

-At the entrance gate, Alice presents her QR code which includes a 
unique identifier for this concert, the date and time of the concert,
  her seat number reservation, her family name and her first name and 
the fact that the ticket price is a discounted price available only
  for the residents of Bamberg.

-If the person controlling the QR-codes at the gate has some doubt that 
Alice is indeed a resident of Bamberg,
  she asks Alice to present her ID card or her passport which includes 
her home address and even more important her picture.
("On the Internet, nobody knows you're a dog". Peter Steiner's cartoon, 
as published in The New Yorker on July 5, 1993).

This is simple, efficient and easy to implement right now.

This is roughly how train reservations are working on the French web 
site oui.sncf. Some one over 60 can request a discounted railway ticket .
If the train controller has some doubt that the bearer of the discounted 
railway ticket is really over 60 after scanning the QR code, he will ask
the person to show an identity card or a passport at the platform 
entrance or while in the train. Not only the year of birth will allow to 
make sure
that the individual is indeed over 60 but in addition the name on the 
identity card or the passport will be checked against the name on the 
railway
ticket and that picture matches with the face of the person in front of 
the train controller.

Anyway, IMHO, I don't believe that this use case should be solved using 
GNAP.

Denis

PS. This use case has been posted here:
https://github.com/ietf-wg-gnap/general/wiki/SSI-integration#alice-purchasing-a-concert-ticket-without-disclosing-her-identity

---

From: Justin Richer <[email-masked]>
Date: Fri, 21 Aug 2020 09:02:03 -0400

The SSI trick is not the ticket — the SSI portion here is "She indicates that she is a resident of Bamberg”. We’d like Alice to be able to do that in a verifiable and programatic way that we can enable in the protocol flow.

 — Justin

> On Aug 21, 2020, at 8:48 AM, Denis <[email-masked]> wrote:
> 
> 
> Hello Francis,
> This WG has not been formed to address SSI (Self sovereign identity). This use case can be solved without using an AS and a RS 
> -          Alice visits the website of AC-Tickets.
> 
> -          Alice looks up and finds "Bamberg Symphony", the concert she wants to attend.
> 
> -          Alice is informed that she can get a discount price if she is a resident of Bamberg.
> 
> -          Alice fills a form and enters the requested information. 
>  She indicates that she is a resident of Bamberg and so she gets the discounted price.
> 
> -          Alice makes the payment using 3D secure.
> 
> -          Alice gets back a QR code on her phone that will be scanned when entering the concert hall.
> 
> -          Alice goes to the concert at Bamberg Symphony.
> 
> -          At the entrance gate, Alice presents her QR code which includes a unique identifier for this concert, the date and time of the concert, 
>  her seat number reservation, her family name and her first name and the fact that the ticket price is a discounted price available only 
> -          If the person controlling the QR-codes at the gate has some doubt that Alice is indeed a resident of Bamberg, 
>  she asks Alice to present her ID card or her passport which includes her home address and even more important her picture.
> ("On the Internet, nobody knows you're a dog". Peter Steiner's cartoon, as published in The New Yorker on July 5, 1993).
> 
> This is roughly how train reservations are working on the French web site oui.sncf. Some one over 60 can request a discounted railway ticket . 
> If the train controller has some doubt that the bearer of the discounted railway ticket is really over 60 after scanning the QR code, he will ask 
> the person to show an identity card or a passport at the platform entrance or while in the train. Not only the year of birth will allow to make sure
> that the individual is indeed over 60 but in addition the name on the identity card or the passport will be checked against the name on the railway 
> ticket and that picture matches with the face of the person in front of the train controller.
> 
> Anyway, IMHO, I don't believe that this use case should be solved using GNAP. 
> 
> Denis 
> 
> https://github.com/ietf-wg-gnap/general/wiki/SSI-integration#alice-purchasing-a-concert-ticket-without-disclosing-her-identity <https://github.com/ietf-wg-gnap/general/wiki/SSI-integration#alice-purchasing-a-concert-ticket-without-disclosing-her-identity>
> -- 
> TXAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Francis Pouatcha <[email-masked]>
Date: Fri, 21 Aug 2020 09:08:59 -0400

Hello Denis,

in your use case description,
- the RS ist the concert gateman
- now AS/GS is AC-Tickets

- AS/GS issue a conditioned token (Please allow Alice to this concert only
if she is older than 18 and a resident of Bamberg)
- Human RS is given an "option" to check these claims at the gate (or not).

- Check is negative: Alice is younger than 18, but has bought a concert
ticket from the ticket website (legal contract). Who is liable?

Best regards
/Francis

On Fri, Aug 21, 2020 at 8:48 AM Denis <[email-masked]> wrote:

> Hello Francis,
>
> This WG has not been formed to address SSI (Self sovereign identity). This
> use case can be solved without using an AS and a RS
> -          At the entrance gate, Alice presents her QR code which
> includes a unique identifier for this concert, the date and time of the
> concert,
>  her seat number reservation, her family name and her first name and the
> fact that the ticket price is a discounted price available only
> -          If the person controlling the QR-codes at the gate has some
> doubt that Alice is indeed a resident of Bamberg,
>  she asks Alice to present her ID card or her passport which includes her
> home address and even more important her picture.
> This is roughly how train reservations are working on the French web site
> oui.sncf. Some one over 60 can request a discounted railway ticket .
> the person to show an identity card or a passport at the platform entrance
> or while in the train. Not only the year of birth will allow to make sure
> that the individual is indeed over 60 but in addition the name on the identity
> card or the passport will be checked against the name on the railway

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

---

From: Francis Pouatcha <[email-masked]>
Date: Fri, 21 Aug 2020 09:14:27 -0400

On Fri, Aug 21, 2020 at 9:02 AM Justin Richer <[email-masked]> wrote:

> The SSI trick is not the ticket — the SSI portion here is "She indicates
> that she is a resident of Bamberg”. We’d like Alice to be able to do that
> in a verifiable and programatic way that we can enable in the protocol flow.
>
Yes.
The purpose of SSI in this use case is to illustrate that authz flows will
have many claim origins. Flows will have many situations where GS relies on
claims produced/presented by other ASs for a compound Authz decision.
Best regards
/Francis

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 21 Aug 2020 15:39:38 +0200

The use case is a bit complex (payment, etc.), but I think there are 2
important items in relation to SSI :
- it is interesting to integrate just like it is with OIDC or FIDO for
instance, SSI is now part of the ecosystem (ex: DID Auth / SIOP is
considered by openid)
- you get the ability to handle somes cases better with verified
credentials (which the example illustrates: it's better to confidently
check the age before you even issue the token). "On the Internet, nobody
knows you're a dog" -> maybe not any more (at least if the issuer wants to
keep his reputation intact).
Btw it helps for privacy too (zkp).

Of course, one can still use GNAP or SSI separately (This use case can be
solved without using an AS and a RS -> maybe but it can also be solved with
AS and RS).

And I don't think it changes the core design of what we're discussing.

Fabien

On Fri, Aug 21, 2020 at 3:14 PM Francis Pouatcha <fpo=
[email-masked]> wrote:

>> that she is a resident of Bamberg”. We’d like Alice to be able to do
>> that in a verifiable and programatic way that we can enable in the protocol
>> flow.
>>
> Yes.

---

From: Andrew Hindle <[email-masked]>
Date: Fri, 21 Aug 2020 14:44:31 +0100

FWIW, in the UMA WG some time ago we explored (at a conceptual level) how
the concept of SSI could/should intersect with the UMA protocol flow.
It's an important consideration, exactly for the reasons that Francis
outlines.  There are plenty of use-cases that are well solved without SSI
(and, indeed, without any need for 'verified' or 'attested' attributes per
se).  But there are also some very important use-cases where this kind of
integration will be important.
I think it's smart to consider this in the GNAP specification design.
--&e

-- 
Andrew Hindle; CIPM <https://www.credential.net/i7iz5rjk>, CIPP/E
<https://www.credential.net/q8vel50x>, CIPT
<https://www.credential.net/442455d1-23e8-4cc2-aac6-dfcfb9140785>
Hindle Consulting Limited
+44 7966 136543
Schedule a meeting <https://freebusy.io/[email-masked]/30min>

-- 

Hindle Consulting Limited is a company registered in England and Wales.  
Company number: 8888564.
Registered office: Claremont House, 1 Market 
Square, Bicester, Oxfordshire OX26 6AA, UK.