Re: [OAUTH-WG] updated Distributed OAuth ID
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 owner >> qualifies for grant type code and distributed OAuth. >> >> Let’s assume a user wants to authorize a client for access to her cloud >> storage, email account and contacts when setting app the respective app. >> > > Would you walk me through the user experience that happened for the client > to do discovery on these three resources? In other words, what did the user > do to get the client to call the resource and get back the 401 response? > > > I would assume the user enters the URLs or identifies the respective > service providers in the app (e.g. by entering her email address). The > client then sends an initial request as described in your draft and gets > back the 401. > 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 all of Google, Microsoft work today. It seems improbable that an end user is going to post multiple resource end points. But I'm interested if you can present such a use case. > > Doing so for several resources will give the client the AS URL for all > involved resources. If the client compares the iss claims it will figure > our all resources are protected by the same AS and can authorize access via > a single authz code grant flow. > Today, if you had a Google hosted email and a Microsoft hosted email, you would have different AS. Do you have another example? > > kind regards, > Torsten. > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt
This text is fine. I have issued IETF-LC.
On Mon, Jun 4, 2018 at 1:45 PM, Brian Campbell
wrote:
> Thanks Eric, I've added text in the just submitted -14 saying that only
> the two ends of the chain are to be considered in access control policy
> decisions.
>
> diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-14
>
> htmlized:
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-14
>
>
> On Fri, Jun 1, 2018 at 10:02 PM, Eric Rescorla wrote:
>
>> OK, well, it seems like it ought to say that that generator of the token
>> can expect that the RP will apply an access control policy that s the union
>> of the capabilities of the two ends of the chain -- and that while it might
>> be less it won't be more.
>>
>> -Ekr
>>
>>
>> On Fri, Jun 1, 2018 at 3:15 PM, Brian Campbell <
>> bcampb...@pingidentity.com> wrote:
>>
>>> I suspect that the vast majority of time C's permissions won't matter at
>>> all. But I do think there are legitimate cases where they might be
>>> considered in the policy decision. One general example I can think of is a
>>> customer service rep or administrator taking override type corrective
>>> action on an end-user's account or transaction information (A is the
>>> end-user and C is the customer service rep) that the user on their own
>>> wouldn't have permission to change.
>>>
>>> On Fri, Jun 1, 2018 at 3:47 PM, Eric Rescorla wrote:
>>>
That would go a long way, I think. Do you think that C's permissions
matter at all? So, say that the resource is accessible to C but not A?
-Ekr
On Fri, Jun 1, 2018 at 11:47 AM, Brian Campbell <
bcampb...@pingidentity.com> wrote:
> Hi Eric,
>
> Apologies for my somewhat slow response. I've honestly been unsure of
> how else to try and address the comment/question. But will continue
> trying...
>
> My expectation would be that access control decisions would be made
> based on the subject of the token itself or on the current actor. And
> maybe
> a combination of both in some situations (like, for example, the actor is
> an administrator and the token allows admin level access to the stuff the
> token subject would normally have access to). However, I don't believe
> that nested prior actors would or should be considered in access control
> decisions. The nesting is more just to express what has happened for
> auditing or tracking or the like. To be honest, the nesting was added in
> the draft largely because the structure naturally and easily allowed for
> it
> and it seemed like it might be useful information to convey in some cases.
>
> So in that A->B->C case (the claims of such a token would, I think,
> look like the JSON below), B *is not* giving C his authority. B is
> just noted in the token as having been involved previously. While A is
> identified as the subject of the token and C is the current actor.
>
> {
> "aud":"... ,"iss":... , "exp":..., etc. etc. ...
> "sub":"A",
> "act":
> {
> "sub":"C",
> "act":
> {
> "sub":"B"
> }
> }
> }
>
>
> Would some text explicitly saying that only the token subject (top
> level sub and claims) and the party identified by the outermost "act"
> claim
> (the current actor) are to be considered in access control decisions
> address your concern?
>
>
> On Tue, May 29, 2018 at 4:19 PM, Eric Rescorla wrote:
>
>> Hi Brian,
>>
>> To be clear, I'm not opposing Delegation. My concern here is that we
>> have a chain of signed assertions and I'm trying to understand how I as a
>> consumer of those assertions am supposed to evaluate it.
>>
>> I don't think it's sufficient to just say that that the access
>> control rules are local policy, because then the entity generating the
>> signature has no way of knowing how its signature will be used.
>>
>> To go back to the case I gave in my initial e-mail, say we have a
>> chain A->B->C and a resource that A and C could ordinarily not access,
>> but
>> B can. If C has this delegation, can C access the resource? I.e., is B
>> giving C his authority or just passing on A's authority? It seems pretty
>> important for B to know that before he gives the token to C.
>>
>> -Ekr
>>
>>
>> On Thu, May 17, 2018 at 11:06 AM, Brian Campbell <
>> bcampb...@pingidentity.com> wrote:
>>
>>> Delegation has been in the document since its inception and
>>> throughout the three and a half years as a working group document.
>>>
>>> From a process point of view, the document is now in AD Evaluation.
>>> I worked through a number of questions and clarifications with Eric
>>> (said
>>> AD), however he raised the particular questions
Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-mtls-10
Thanks Brian! I have just made these two changes to the write-up. Regards, Rifaat On Sun, Jul 22, 2018 at 5:13 PM Brian Campbell wrote: > In (1), could it maybe say "normative extensions" rather than "normative > changes"? > > Also Ping Identity is two words (rather than "PingIdentity"). > > Otherwise, it looks great. Thanks Rifaat! > > On Sat, Jul 21, 2018 at 3:25 PM, Rifaat Shekh-Yusef > wrote: > >> All, >> >> The following is the shepherd write-up for the draft-ietf-oauth-mtls-10 >> document: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/shepherdwriteup/ >> >> Please, take a look and let us know if you have any comments. >> >> Regards, >> Rifaat & Hannes >> >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-mtls-10
In (1), could it maybe say "normative extensions" rather than "normative changes"? Also Ping Identity is two words (rather than "PingIdentity"). Otherwise, it looks great. Thanks Rifaat! On Sat, Jul 21, 2018 at 3:25 PM, Rifaat Shekh-Yusef wrote: > All, > > The following is the shepherd write-up for the draft-ietf-oauth-mtls-10 > document: > https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/shepherdwriteup/ > > Please, take a look and let us know if you have any comments. > > Regards, > Rifaat & Hannes > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Content of OAuth Digest, Vol 117, Issue 43
> > -- > > Message: 4 > Date: Sat, 21 Jul 2018 17:58:28 -0400 > From: Rifaat Shekh-Yusef > To: Torsten Lodderstedt > Cc: oauth > Subject: Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-mtls-10 > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Thanks Torsten! > > > On Saturday, July 21, 2018, Torsten Lodderstedt > wrote: > > > Hi Rifaat, > > > > Berlin Group?s Nextgen PSD2 Spec (https://docs.wixstatic.com/ugd/c2914b_ > > 5351b289bf844c6881e46ee3561d95bb.pdf) also refers to mTLS. > > > > kind regards, > > Torsten. > > > > Am 21.07.2018 um 23:25 schrieb Rifaat Shekh-Yusef > > : > > > > All, > > > > The following is the shepherd write-up for the drafts-ietf-oauth-mtls-10 > > document: > > https://data > > <https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/shepherdwriteup/> > > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/shepherdwriteup/ > > tracker.ietf.org/doc/draft-ietf-oauth-mtls/shepherdwriteup/ > > <https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/shepherdwriteup/> > > > > > > > > Please, take a look and let us know if you have any comments. > > > > Regards, > > Rifaat & Hannes > > > > ___ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- next part -- > An HTML attachment was scrubbed... > URL: > <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20180721/5fe9b9c5/attachment.html> > > > -- > > Message: 5 > Date: Sun, 22 Jul 2018 08:53:44 -0600 > From: Brian Campbell > To: Filip Skokan > Cc: oauth > Subject: Re: [OAUTH-WG] regarding draft-ietf-oauth-jwsreq > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > I believe Filip is correct on these. > > On Sat, Jul 21, 2018 at 1:03 PM, Filip Skokanwrote: > > > Hello, > > > > about the mentioned content-types in the current draft *jwsreq-16* > > > > in *section-10.4.1* - says to > > > > check the content type of the response is "application/jose" > > > > > > I believe this should be application/jwt instead > > > > in *section-10.4.2* - says to > > > > check the content type of the response is "application/json" > > > > > > I believe this should be application/jwt too > > > > Both to be in line with the example of fetch response from > > *section-5.2.3 * > > > > Best, > > *Filip Skokan* > > > > ___ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited.? If you have > received this communication in error, please notify the sender immediately > by e-mail and delete the message and any file attachments from your > computer. Thank you._ > -- next part -- > An HTML attachment was scrubbed... > URL: > <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20180722/332f031f/attachment.html> > > > -- > > Subject: Digest Footer > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > -- > > End of OAuth Digest, Vol 117, Issue 43 > ** > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] regarding draft-ietf-oauth-jwsreq
I believe Filip is correct on these. On Sat, Jul 21, 2018 at 1:03 PM, Filip Skokan wrote: > Hello, > > about the mentioned content-types in the current draft *jwsreq-16* > > in *section-10.4.1* - says to > > check the content type of the response is "application/jose" > > > I believe this should be application/jwt instead > > in *section-10.4.2* - says to > > check the content type of the response is "application/json" > > > I believe this should be application/jwt too > > Both to be in line with the example of fetch response from > *section-5.2.3 * > > Best, > *Filip Skokan* > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
