MIME-Version: 1.0
References: <BD2D90C8-B629-4955-A22C-6E80E6390EEE@mit.edu>
 <CAD9ie-uReSZ8Ds5O20ERHJ__+VrOKVPy3Simi+gKLvqzpC61gQ@mail.gmail.com>
In-Reply-To: <CAD9ie-uReSZ8Ds5O20ERHJ__+VrOKVPy3Simi+gKLvqzpC61gQ@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
Date: Mon, 22 Jul 2019 12:21:37 -0400
Message-ID: <CABzCy2B-a3+4XOdcUM4DBS_VyuqF9NfWuWdYc1n3auOfR7twSw@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, oauth <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/azaHvtkOv5La2dWqoPgd0vELIMs>
Subject: Re: [OAUTH-WG] Transaction Authorization
Precedence: list

+1

Also, if it were to include user identification in the protocol, I
would like to have the spec at least cover the following:

0. User
1. External Identity Provider
2. Resources that covers the functionality of PEP.
3. Authorization Server that act as PDP for  Resources.
4. Internal Identity Server within the resource domain.
5. Client APP component
6. Client Server component

In addition, it would be good to delineate the resource owner (an
entity that has administrative rights over the set of resources) and
the end user who is in the protocol flow.

That actually asks for the following additional entities:

7. Resource Administrator
8. PAP/PIP

It is probably a good idea to state the security target as well.

Re: Starting from Resource.

Yes. I agree that this is a valid use case. At the same time, there
can be cases where the concrete resource endpoint is not known before
the user authorization. So, the protocol needs to be able to start
both ways, I guess.

Cheers,

Nat Sakimura


On Sun, Jul 21, 2019 at 5:28 PM Dick Hardt <dick.hardt@gmail.com> wrote:
>
> Hey Justin
>
> A few use cases that highlight how the world is different now than it was=
 when OAuth 2.0 was developed would help participants understand why change=
s are needed, and also provide a reference for comparing and contrasting di=
fferent approaches.
>
> One of my first comments is why the client is starting off making calls t=
o the AS. There are times when the AS is not known for a given resource. Wh=
y not allow starting at resource?
>
>
> On Tue, Jul 9, 2019 at 12:48 PM Justin Richer <jricher@mit.edu> wrote:
>>
>> I have requested time to present Transactional Authorization (the XYZ pr=
oject) at the Montreal meeting in a couple weeks. Ahead of that, I=E2=80=99=
ve uploaded a new version of the spec:
>>
>> https://tools.ietf.org/html/draft-richer-transactional-authz-02
>>
>> Additionally, I=E2=80=99ve updated the writeup and examples on https://o=
auth.xyz/
>>
>> I plan to be in Montreal for the whole week, and I=E2=80=99ve requested =
from the chairs that I present during the Tuesday session due to limited av=
ailability of some key WG members on Friday.
>>
>> =E2=80=94 Justin
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en