Re: [OAUTH-WG] OAuth Recharting

[Hannes Tschofenig <[e-mail]>]

Hi Kepeng,

I intentionally kept the wording vague to have a bit of freedom when we
do the call for adoption of specific documents.

Having said that I will post a mail to the list to bring up a few
concerns regarding the scope of the PoP work that have been brought to
my attention.

Ciao
Hannes


On 12/18/2015 01:59 AM, Kepeng Li wrote:
> Hi Hannes,
> 
> Thanks for putting this together.
> 
>> and specifications that mitigate security attacks, such as Proof Key for
>> Code Exchange.
> 
> 
> I propose to change it to:
> 
> and specifications that mitigate security attacks, such as Proof Key for
> Code Exchange, and Sender Constraint JSON Web Token.
> 
> 
> Sender Constaint JWT is mentioned in PoP architecture document, but it is
> not 
> specified in detail. That is why we provided a separate draft for that.
> 
> 
> Thanks,
> 
> Kind Regards
> Kepeng
> 
> 在 17/12/15 11:59 pm， "Hannes Tschofenig" <[e-mail]> 写入:
> 
>> Hi all,
>>
>> at the last IETF meeting in Yokohama we had a rechartering discussion
>> and below is proposed text for the new charter. Please take a look at it
>> and tell me whether it appropriately covers the discussions from our
>> last meeting.
>>
>> ---------------
>>
>> Charter Text
>>
>> The Web Authorization (OAuth) protocol allows a user to grant a
>> third-party Web site or application access to the user's protected
>> resources, without necessarily revealing their long-term credentials,
>> or even their identity. For example, a photo-sharing site that
>> supports OAuth could allow its users to use a third-party printing Web
>> site to print their private pictures, without allowing the printing
>> site to gain full control of the user's account and without having the
>> user share his or her photo-sharing sites' long-term credential with
>> the printing site.
>>
>> The OAuth 2.0 protocol suite already includes
>>
>> * a procedure for enabling a client to register with an authorization
>> server,
>> * a protocol for obtaining authorization tokens from an authorization
>> server with the resource owner's consent, and
>> * protocols for presenting these authorization tokens to protected
>> resources for access to a resource.
>>
>> This protocol suite has been enhanced with functionality for
>> interworking with legacy identity infrastructure (e.g., SAML), token
>> revocation, token exchange, dynamic client registration, token
>> introspection, a standardized token format with the JSON Web Token, and
>> specifications that mitigate security attacks, such as Proof Key for
>> Code Exchange.
>>
>> The ongoing standardization efforts within the OAuth working group
>> focus on increasing interoperability of OAuth deployments and to
>> improve security. More specifically, the working group is defining proof
>> of possession tokens, developing a discovery mechanism,
>> providing guidance for the use of OAuth with native apps, re-introducing
>> the device flow used by devices with limited user interfaces, additional
>> security enhancements for clients communicating with multiple service
>> providers, definition of claims used with JSON Web Tokens, techniques to
>> mitigate open redirector attacks, as well as guidance on encoding state
>> information.
>>
>> For feedback and discussion about our specifications please
>> subscribe to our public mailing list.
>>
>> For security related bug reports that relate to our specifications
>> please contact <<TBD>>. If the reported bug
>> report turns out to be implementation-specific we will
>> attempt to forward it to the appropriate developers.
>>
>> ---------------
>>
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> 
>