Subject: [OAUTH-WG] OAuth Recharting

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 17 Dec 2015 16:59:35 +0100

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

---

From: William Denniss <[email-masked]>
Date: Thu, 17 Dec 2015 15:06:50 -0800

Looks good to me Hannes, thanks for putting it together!

On Thu, Dec 17, 2015 at 7:59 AM, Hannes Tschofenig <
[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: "Kepeng Li" <[email-masked]>
Date: Fri, 18 Dec 2015 08:59:44 +0800

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 22 Dec 2015 09:03:48 +0100

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