gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: About re:claimID


From: Alessio Vanni
Subject: Re: About re:claimID
Date: Sun, 06 Dec 2020 15:45:58 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Martin Schanzenbach <mschanzenbach@posteo.de> writes:

> The gist of the flow is also here:
> https://docs.gnunet.org/handbook/gnunet.html#reclaimID-Identity-Provider

Thank you, completely forgot about the handbook!

> Basically:
> 1. A relying party requests a set of attributes from the user
> 2. The user decides if he wants to share the attributes (if no,
> protocol ends).
> 3. The user issues a ticket for the relying party for the specific set
> of attributes.
> 4. The user transfers the ticket to the relying part (out of band!).
> 5. The relying party can retrieve the requested attributes using the
> ticket.

I understand.

> One thing to note is that reclaimID by itself is just a means to
> *authorize access to identity attributes*.
> In other words, it is not directly a means to authenticate.
> This is a common misconception.

And in fact I misunderstood it ;)
Thanks for clarifying.

> This leaves you with a last problem (that you could also just ignore
> depending on the use case): Establishing trust in the requesting party
> = Bob.
> Why should the user trust Bob with a ticket or provide an
> authentication response to him?

In my specific case, Bob offers a service that Alice wants to use, so to
use the service she has to completely trust Bob.  It's Alice that
requests Bob to set up the service to accept authentication attempts
from Alice, so she has to trust him before sending tickets or anything
else.

> "Peeking" over his shoulders (in real life) is still possible, of
> course. But I do not see a reason why you would ever actually display
> the ticket/label to the user.

It was just a humourous way to say that there could be an observer
looking for tickets. ;) Since you said that tickets should be sent
through an encrypted channel, then I shall do that.

Unless I'm missing something else, I could do something like this for my
use case:

+ Alice and Bob communicate through some channel that Alice wants to use
  Bob's service, so Bob sets it up for her
+ Alice issues a re:claimID ticket for Bob with some previously agreed
  upon attributes.
+ Alice sends the ticket to Bob through some secure channel
+ When Alice wants to authenticate, Bob sends her a challenge based on
  the contents of the ticket, e.g. he asks to sign a certain string
+ If the challenge is successful, Alice is authenticated with the
  service.

Does that make sense to you? Is re:claimID used correctly?

Thanks,
A.V.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]