The OAuth Device Flow specification (full name "OAuth 2.0 Device Flow for
Browserless and Input Constrained Devices") has been updated to address
comments received to date from the IETF last call. Thanks to William
Denniss
for taking the pen for this set of revisions. Changes were:
*
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
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
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
wrote:
> Hi Eric,
>
> Apologies for my somewhat slow response. I've honestly been unsure of how
>
On Thu, May 31, 2018 at 9:49 AM, Brian Campbell
wrote:
>
>
> On Wed, May 30, 2018 at 6:06 PM, William Denniss
> wrote:
>
>>
>> On Wed, May 30, 2018 at 3:48 PM, Brian Campbell <
>> bcampb...@pingidentity.com> wrote:
>>
>>> I realize this is somewhat pedantic but I don't think referencing 4.1.2.1
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.
Title : OAuth 2.0 Device Flow for Browserless and Input
Constrained Devices
Authors : William Denniss
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
Thank you Travis for your feedback!
Am 20.03.18 um 12:48 schrieb Travis Spencer:
> I read through this doc and would like to share a bit of feedback in
> hopes that it helps:
>
> * There is no mention of Content Security Policy (CSP). This is a very
> helpful security mechanism that all OAuth
Hi all,
I didn't see this posted here before. This conference might be
interesting for some of you.
-Daniel
Forwarded Message
Conference on Security Standardisation Research (SSR) 2018
26-27 November
What is the expectation if the RS requests a signed JWT response but the
AS doesn't support it? Should getting a signed response require both?
(meaning the Accept header and an AS config that that RP wants it)? That
may be the safest from a backward compatibility perspective.
I have some
Hi Matt,
I think your use case is fully within the use cases enabled by
software-statements.
A per client software-statement allows you to tighten the security model
(if desired). For example binding the software-statement to the client
presenting it in such a way as to have a cryptographic
I'm fine with it being optional but I don't think it should be removed.
I have a use case where the actor_token is being used. In my use case
the "actor" represents a device making a token exchange between two
applications running on the device. It allows the AS to enforce a
binding such that
Hi George,
That did occur to me. It seemed like a bit of an abuse of the
software-statement system, but maybe it is partially intended for this.
It still needs us to securely distribute the software statement as well. Would
you envisage a single software-statement for all installations, with
Given that you have a federation, could not the federation issue the
signed software-statement to each of the relying parties (existing or
old) and the AS will trust the dynamic client registration if and only
if the signed software-statement is signed by the federation. This fits
more closely
Hi,
I am working on a use case of OAuth 2.0 in a federation and am after some
advice about bootstrapping trust.
Each site in the federation has an OAuth 2.0 authorization server and an OAuth
2.0 relying party. The relying party at each site needs to be registered with
all the authorization
15 matches
Mail list logo
