Hi All,
In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resource
Server"), RFC6819 describes a threat where a counterfeit resource server
tricks a client into obtaining and sharing an access token from a
legitimate authorization server. One of the proposed mitigations involves:
"te
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : OAuth 2.0 Proof-of-Possession (PoP) Security
Architecture
Authors : Phil Hunt
Hi Reddy,
thanks a lot for your review comments and for failing to notice them.
On 08/28/2014 09:05 AM, Tirumaleswar Reddy (tireddy) wrote:
> My comments:
>
>
>
> 1) Figure 3: Resource server in the response could also generate
> Signature/MAC to prove the client that it is in possession of
>
Hi Hannes,
Sent from my iPhone
> On Mar 3, 2015, at 4:50 AM, Hannes Tschofenig
> wrote:
>
> Hi Kathleen,
>
> the statement about the IANA actions in the shepherd writeup are indeed
> incorrect. I updated the writeup.
Thank you!
>
>>>IANA Considerations:
>>>The shepherd repor
Hi Justin, Hi all,
here are some random review comments:
FROM:
" Since
OAuth 2.0 [RFC6749] defines no direct relationship between the
authorization server and the protected resource, only that they must
have an agreement on the tokens themselves, there have been many
different appr
Hi Justin, Hi all,
in OAuth we provide two ways for a resource server to make an
authorization decision.
1) The resource server receives a self-contained token that contains all
the necessary information to make a local authorization decision. With
the JWT we have created such a standardized info
Hi Kathleen,
the statement about the IANA actions in the shepherd writeup are indeed
incorrect. I updated the writeup.
>> IANA Considerations:
>> The shepherd report says that there are no actions for IANA,
>> so this needs to be updated as the draft is the specification
>
