>
> We are building up the scheme. One banking group is deployed.
>
>>
>> Today, a separate flow us required for each RS, correct?
>
> We support combined flows because this is a key requirement for us. But this
> comes at a price: we cannot tightly audience restrict our tokens. We use
>
> Am 24.07.2018 um 22:51 schrieb Dick Hardt :
>
> Ok. I think I understand the use case now. Would you confirm?
>
> These are deployed today, correct?
We are building up the scheme. One banking group is deployed.
>
> Today, a separate flow us required for each RS, correct?
We support
Ok. I think I understand the use case now. Would you confirm?
These are deployed today, correct?
Today, a separate flow us required for each RS, correct?
In the future, you would like the client to ask for multiple resources that
are managed by the same AS, correct?
On Tue, Jul 24, 2018 at
For every bank (and their customers) there is a set of services run by the bank
or other entities, which rely on the AS of the particular bank for
authorization. In some cases, a service may bring its own AS to the party (due
to technical restrictionions). So an RP binding to a certain
I'm trying to understand the use case.
It still is vague. Are you saying that each of these is run by a different
entity, but all trust the bank as the authorization server to manage if the
user has granted permission to use the resource rather than managing it
themselves?
account information,
> And who is the AS?
In case of yes, it’s typically the bank. At Deutsche Telekom, it is the central
AS/IDP.
Why are you asking?
>
>> On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt
>> wrote:
>>
>>> Am 23.07.2018 um 13:58 schrieb Dick Hardt :
>>>
>>> In your examples, are these
And who is the AS?
On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
>
> Am 23.07.2018 um 13:58 schrieb Dick Hardt :
>
> In your examples, are these the same AS?
>
>
> yes
>
>
>
>
> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt <
>
> Am 23.07.2018 um 13:58 schrieb Dick Hardt :
>
> In your examples, are these the same AS?
yes
>
>
>
>> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt
>> wrote:
>> Hi Dick,
>>
>> > Am 23.07.2018 um 00:52 schrieb Dick Hardt :
>> >
>> > Entering in an email address that resolves to a
In your examples, are these the same AS?
On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt
wrote:
> Hi Dick,
>
> > Am 23.07.2018 um 00:52 schrieb Dick Hardt :
> >
> > Entering in an email address that resolves to a resource makes sense. It
> would seem that even if this was email, calendar
Hi Dick,
> Am 23.07.2018 um 00:52 schrieb Dick Hardt :
>
> Entering in an email address that resolves to a resource makes sense. It
> would seem that even if this was email, calendar etc. -- that those would be
> different scopes for the same AS, not even different resources. That is how
>
On Sat, Jul 21, 2018 at 12:49 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> Hi Dick,
>
> Am 19.07.2018 um 15:46 schrieb Dick Hardt :
>
> I think any scenario with multiple resource servers relying on the same AS
>> for authorization where the client acts on behalf of the resource
Hi Dick,
Am 19.07.2018 um 15:46 schrieb Dick Hardt :
>> I think any scenario with multiple resource servers relying on the same AS
>> for authorization where the client acts on behalf of the resource owner
>> qualifies for grant type code and distributed OAuth.
>>
>> Let’s assume a user
Waite
> Sent: Thursday, July 19, 2018 4:55 PM
> To: Dick Hardt
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] updated Distributed OAuth ID
>
> Four comments.
>
> First: What is the rationale for including the parameters as Link headers
> rather than part of th
; Nat Sakimura
>
>
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of David Waite
> Sent: Thursday, July 19, 2018 4:55 PM
> To: Dick Hardt
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] updated Distributed OAuth ID
>
> Four comments.
>
> First: What is the
19, 2018 4:55 PM
To: Dick Hardt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] updated Distributed OAuth ID
Four comments.
First: What is the rationale for including the parameters as Link headers
rather than part of the WWW-Authenticate challenge, e.g.:
WWW-Authenticate: Bearer realm="example_
On Thu, Jul 19, 2018 at 8:51 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> Hi Dick,
>
>
>
>>
>> Section 3:
>> Don’t you think it could be a useful information to have the resource URI
>> available in the authorization flow?I would assume it could have some
>> additional meaning to
David, thanks for the detailed feedback ... responses inline ...
On Thu, Jul 19, 2018 at 3:54 AM, David Waite
wrote:
> Four comments.
>
> First: What is the rationale for including the parameters as Link headers
> rather than part of the WWW-Authenticate challenge, e.g.:
>
> WWW-Authenticate:
Hi Dick,
>
>>
>> Section 3:
>> Don’t you think it could be a useful information to have the resource URI
>> available in the authorization flow?I would assume it could have some
>> additional meaning to the AS and could also be the context of the scope.
>
> I'm assuming you are referring
Four comments.
First: What is the rationale for including the parameters as Link headers
rather than part of the WWW-Authenticate challenge, e.g.:
WWW-Authenticate: Bearer realm="example_realm",
scope="example_scope",
Thanks for the review Torsten! ... comments inserted ...
On Tue, Jul 17, 2018 at 11:59 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> Hi Dick,
>
> I like the draft! It puts together some best practices relevant for
> dynamic OAuth in a reasonable way.
>
> Some comments:
>
> Section
Hi Dick,
I like the draft! It puts together some best practices relevant for dynamic
OAuth in a reasonable way.
Some comments:
Section 2:
I appreciate the idea to let the resource determine its resource URI (later
used as aud of the access token). This will allow the RS to segment and group
Thanks for the review and suggestions, Jared. A token (pun intended!)
attempt at addressing your comments follows.
Though I don't think I actually discussed it with my co-authors, I did
think about the link relation for the AS being the issuer rather than
pointing to the metadata document under
Hey OAuth WG
I have worked with Nat and Brian to merge our concepts and those are
captured in the updated draft.
https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/
We are hopeful the WG will adopt this draft as a WG document.
Any comments and feedback are welcome!
/Dick
23 matches
Mail list logo