[Top][All Lists]

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

Re: About re:claimID

From: Martin Schanzenbach
Subject: Re: About re:claimID
Date: Mon, 07 Dec 2020 00:22:41 +0900
User-agent: Evolution 3.38.1 (3.38.1-1.fc33)

On Sun, 2020-12-06 at 15:45 +0100, Alessio Vanni wrote:
> Martin Schanzenbach <> writes:
> > The gist of the flow is also here:
> >
> 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.

Yes. Beware that Alice not only needs to trust Bob, but she also must
be able to authenticate Bob. Only having *a* secure channel to Bob's
service could lead to a MitM attack. It must be a channel with Bob
*and* Bob must be trusted (in some way).
Again, as an example think TLS: When you browse to,
you can be sure that you actually talk to our servers because of the
server authentication against the domain name (X509 PKI).

> > "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

Yes. See above. This might be a delicate part.

> + 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.

Yes. Note that if Bob receives just any Ticket (appearing to come from
Alice) without having authenticated Alice it may actually originate
from another party (impersonation).
So authentication of the ticket issuer is recommended.

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



> Thanks,
> A.V.

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

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