Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)

We have addressed that problem w/i Kantara and have a proposed solution.
See link below.
But there is a caveat.
You MUST stop using the term trust - it has no agreed meaning.
So you must define what attribute needs attestation.
In our case we identified three things that the second party needs to know.
we also stop trying to define the difference between the client and the rs.
At least in our case two parties could switch roles w/i milliseconds.
We defined these attributes to be shared between parties of the many that
could be spec'd.
1. identify proofing
2. authentication proofing
3. proof of presence
each had to be a signed assertion that was included in the az token.
perhaps this model could work for this wg?
https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token
Peace ..tom

On Mon, Jun 29, 2020 at 9:02 AM Mike Varley <mike.varley@securekey.com>
wrote:

> Hello Denis, all, I just wanted to jump in on this point below:
>
>
>
> *From: *Txauth <txauth-bounces@ietf.org> on behalf of Denis <
> denis.ietf@free.fr>
> *Date: *Monday, June 29, 2020 at 3:14 AM
>
> Any trust relationship may be described using the following construction:
> entity A trusts entity B for some action C.
> If you have in mind additional trust relationships, would you be able to
> express them using this construction ?
> Maybe you also have in mind some relationships that do not imply a form of
> trust ?
>
>
>
> There is a proxy/broker model which sort of is described by the above, but
> I’d like to call out below.
>
> There are cases where A trusts Z and  B trusts Z, but A and B do not
> know/trust each other directly, and Z is Not the AS (but there is a trust
> relationship between Z and the AS – this allows for more than one AS in the
> trust framework). In order for A and B to interact, the AS will act as a
> ‘locator’ service and subject-representative, but any associated access
> tokens the AS generate will require assurances from Z that the participants
> in the transaction are legitimate entities in the transaction.
>
> Here is a for example: A is a rental car company, B is a DMV. The AS is a
> personal digital identity management service (*cough* wallet **cough**)
> that interacts with the license holder/Renter. A, B, and AS have a trust
> relationship and defined role in an organization Z. When the Renter wishes
> to provide his eligibility to drive to A, the AS must provide:
>
>    1. Evidence to A from Z that B is a qualified DMV (permitted to
>    provide the required info).
>    2. Evidence to B from Z that A is a qualified Rental Car Company
>    (permitted to collect the required into).
>    3. Evidence to both A and B from Z that the AS is a trusted subject
>    representative.
>    4. A route for A and B to communicate with each other with all these
>    access permissions.
>
> Note in this model the AS can also be a trusted participant in another Z+1
> trust framework.
>
> I see GNAP as an opportunity to support the above model with flexible user
> agents, AS, discovery, token structures and crypto.
>
> Thanks,
>
> MV
>
> This email and any attachments are for the sole use of the intended
> recipients and may be privileged, confidential or otherwise exempt from
> disclosure under law. Any distribution, printing or other use by anyone
> other than the intended recipient is prohibited. If you are not an intended
> recipient, please contact the sender immediately, and permanently delete
> this email and its attachments.
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>