Subject: [OAUTH-WG] OAuth WG Re-Chartering

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 14 Mar 2012 22:21:15 +0200

So, here is a proposal:

-------

Web Authorization Protocol (oauth)

Description of Working Group

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 
sharing his or her photo-sharing sites' long-term credential with the 
printing site. 

The OAuth protocol suite encompasses
* a procedure for allowing a client to discover a resource server, 
* a protocol for obtaining authorization tokens from an authorization 
server with the resource owner's consent, 
* protocols for presenting these authorization tokens to protected 
resources for access to a resource, and 
* consequently for sharing data in a security and privacy respective way.

In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
was published as an informational document (RFC 5849). With the 
completion of OAuth 1.0 the working group started their work on OAuth 2.0
to incorporate implementation experience with version 1.0, additional
use cases, and various other security, readability, and interoperability
improvements. An extensive security analysis was conducted and the result 
is available as a stand-alone document offering guidance for audiences 
beyond the community of protocol implementers.

The working group also developed security schemes for presenting authorization
tokens to access a protected resource. This led to the publication of
the bearer token as well as the message authentication code (MAC) access 
authentication specification. 

OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with 
the SAML 2.0 bearer assertion profile.  This offers interworking with existing 
identity management solutions, in particular SAML based deployments.

OAuth has enjoyed widespread adoption by the Internet application service provider 
community. To build on this success we aim for nothing more than to make OAuth the 
authorization framework of choice for any Internet protocol. Consequently, the 
ongoing standardization effort within the OAuth working group is focused on 
enhancing interoperability of OAuth deployments. While the core OAuth specification 
truly is an important building block it relies on other specifications in order to 
claim completeness. Luckily, these components already exist and have been deployed 
on the Internet. Through the IETF standards process they will be improved in 
quality and will undergo a rigorous review process. 

Goals and Milestones

[Editor's Note: Here are the completed items.] 

Done 	Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item
Done 	Submit 'HTTP Authentication: MAC Authentication' as a working group item
Done  	Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard
Done 	Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard

[Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?] 

Jun. 2012 	Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard
Apr. 2012 	Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard
Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard 
Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard 
May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC

[Editor's Note: New work for the group. 5 items maximum! ]

Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]

Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be http://tools.ietf.org/html/draft-jones-json-web-token]

Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]

Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be http://tools.ietf.org/html/draft-hardjono-oauth-dynreg] 

Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC

[Starting point for the work will be http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 14 Mar 2012 16:26:07 -0400

Looks good and comprehensive to me.

Igor

On 3/14/2012 4:21 PM, Hannes Tschofenig wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer <[email-masked]>
Date: Wed, 14 Mar 2012 13:33:34 -0700

Looks great!

Not sure if 'JSON Web Token (JWT)' belongs on this list, but not a big problem.

EH

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hannes Tschofenig
> Sent: Wednesday, March 14, 2012 1:21 PM
> To: [email-masked] WG
> Subject: [OAUTH-WG] OAuth WG Re-Chartering
> 
> So, here is a proposal:
> 
> -------
> 
> Jun. 2012 	Submit 'HTTP Authentication: MAC Authentication' to the
> IESG for consideration as a Proposed Standard
> Apr. 2012 	Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to
> the IESG for consideration as a Proposed Standard
> May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations' to
> the IESG for consideration as an Informational RFC
> 
> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth
> 2.0' to the IESG for consideration as a Proposed Standard
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 14 Mar 2012 20:54:44 +0000

This is missing Simple Web Discovery, which there was substantial support for including during the rechartering discussion in Taipei.  Considering OpenID Connect as a motivating use case for OAuth, SWD is the one spec that would then be missing for this OAuth use case.

Please add it to the list.

Thanks,
-- Mike
________________________________
From: Hannes Tschofenig
Sent: 3/14/2012 1:21 PM
To: [email-masked] WG
Subject: [OAUTH-WG] OAuth WG Re-Chartering

So, here is a proposal:

-------

Goals and Milestones

---

From: Eran Hammer <[email-masked]>
Date: Wed, 14 Mar 2012 14:43:26 -0700

I am strongly opposed to SWD being part of *this* working group. My objection is based on:

1.       This is clearly an APP area document, not a SEC area document. Getting this work done through the OAuth WG will skip the most relevant audience for this document as a general purpose tool.

2.       This has nothing to do with OAuth directly. It has the same "enabling" relationship to OAuth as HTTP or JSON.

3.       This work overlaps with other efforts at the IETF, W3C, and OASIS. If there is strong interest in this work, it should first be coordinated with the other groups and organizations.

4.       The APPs AD should look into creating a new WG for this if there is strong interest, but I believe this belongs on the APPs General WG.

5.       The OpenID Foundation is free to standardize this within its own process as it chose to do with many other documents related to OpenID. I would assume the OpenID Foundation values their work and reputation enough to stand behind this if they require it for other foundation work.

This is not an objection to SWD in general (nor an endorsement), just an objection to this work belonging in the OAuth working group.

Btw, there is existing history here. XRD, JRD, host-meta, and well-known URIs were all initiated originally as part of OAuth 1.0 Discovery, but no one working on these efforts suggested they belonged in the OAuth WG.

EH

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, March 14, 2012 1:55 PM
To: Hannes Tschofenig; [email-masked] WG
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

Thanks,
-- Mike
________________________________
From: Hannes Tschofenig
Sent: 3/14/2012 1:21 PM
To: [email-masked]<mailto:[email-masked]> WG
Subject: [OAUTH-WG] OAuth WG Re-Chartering
So, here is a proposal:

-------

Goals and Milestones

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

---

From: "Richer, Justin P." <[email-masked]>
Date: Wed, 14 Mar 2012 21:53:39 +0000

Methods of connecting the PR to the AS are something that several groups have invented outside of the OAuth WG, and I think we should try to pull some of this work together. OAuth2 gives us a logical separation of the concerns but not a way to knit them back together. 

Proposals for inclusion in the discussion include UMA's Step 3, OpenID Connect's CheckID, and several "token introspection" endpoints in various implementations.

 -- Justin

---

From: Eran Hammer <[email-masked]>
Date: Wed, 14 Mar 2012 15:02:42 -0700

The best way is to get some drafts going and then revisit after the proposed charter is completed. I think the 5 new items limit along with the existing work is as much as this WG can take for the time being.

Getting some market experience would be great too.

EH

> Of Richer, Justin P.
> Sent: Wednesday, March 14, 2012 2:54 PM
> To: Hannes Tschofenig
> Cc: [email-masked] WG
> Methods of connecting the PR to the AS are something that several groups
> have invented outside of the OAuth WG, and I think we should try to pull
> some of this work together. OAuth2 gives us a logical separation of the
> concerns but not a way to knit them back together.
> 
> Proposals for inclusion in the discussion include UMA's Step 3, OpenID
> Connect's CheckID, and several "token introspection" endpoints in various
> implementations.
> 
>  -- Justin
> 
> > The Web Authorization (OAuth) protocol allows a user to grant a
> > third-party Web site or application access to the user's protected
> > 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 sharing his or her photo-sharing sites' long-term credential with
> > the printing site.
> >
> > completion of OAuth 1.0 the working group started their work on OAuth
> > 2.0 to incorporate implementation experience with version 1.0,
> > additional use cases, and various other security, readability, and
> > interoperability improvements. An extensive security analysis was
> > conducted and the result is available as a stand-alone document
> > offering guidance for audiences beyond the community of protocol
> implementers.
> >
> > The working group also developed security schemes for presenting
> > authorization tokens to access a protected resource. This led to the
> > publication of the bearer token as well as the message authentication
> > code (MAC) access authentication specification.
> >
> > OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH
> > token with the SAML 2.0 bearer assertion profile.  This offers
> > interworking with existing identity management solutions, in particular
> SAML based deployments.
> >
> > OAuth has enjoyed widespread adoption by the Internet application
> > service provider community. To build on this success we aim for
> > nothing more than to make OAuth the authorization framework of choice
> > for any Internet protocol. Consequently, the ongoing standardization
> > effort within the OAuth working group is focused on enhancing
> > interoperability of OAuth deployments. While the core OAuth
> > specification truly is an important building block it relies on other
> > specifications in order to claim completeness. Luckily, these
> > components already exist and have been deployed on the Internet.
> Through the IETF standards process they will be improved in quality and will
> undergo a rigorous review process.
> >
> > Goals and Milestones
> >
> > Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for
> > consideration as a Proposed Standard Apr. 2012  Submit 'An IETF URN Sub-
> Namespace for OAuth' to the IESG for consideration as a Proposed Standard
> > [Starting point for the work will be
> > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]
> >
> > [Starting point for the work will be
> > http://tools.ietf.org/html/draft-jones-json-web-token]
> >
> > Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for
> OAuth 2.0' to the IESG for consideration as a Proposed Standard
> >
> > [Starting point for the work will be
> > http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]
> >
> > [Starting point for the work will be
> > http://tools.ietf.org/html/draft-hardjono-oauth-dynreg]
> >
> > [Starting point for the work will be
> > http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]
> >
> >
> >

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 14 Mar 2012 22:51:06 +0000

Agree contents looks good

Sent from my Windows Phone
________________________________
From: Igor Faynberg
Sent: 3/14/2012 4:26 PM
To: [email-masked]
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

Igor

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 15 Mar 2012 02:51:19 +0000

Makes sense to limit the scope within this WG and try to spin new ones where appropriate for other work (or find homes in others). We wouldn't want the OAuth WG to just be a convenient hanging-point for vaguely related things. That said, the AS-PR connection is a real and present known gap introduced in OAuth2 (since OAuth1 didn't even think of them as separate entities) and *somebody* should be trying to codify the best ways to fill that gap and I think this is a good place to do it.

Along those lines, I don't think that SWD really belongs in the OAuth group either *except* for the fact that there's a Discovery mandate below that nobody's contesting. It's arguable that this simply covers the WWW-Authenticate header and its value in different contexts, but we all know this is incomplete discovery at best. JWT also doesn't feel like it really belongs here, but since JOSE won't have it, it's a fairly important orphan that's already seeing deployment experience.

Add to all of this that I have two other drafts that I'd like to see dusted off and moved forward through some process -- alternate encoding (XML and Form parameters) from the token endpoint, and the UX/dynreg related "instance information" draft. I'll have versions of both of these uploaded once the IETF tracker takes the locks off at the end of the month. Neither of these saw much WG feedback or support before, though, so I'm open to suggestions of what a better home for them might be, if there is one. Or maybe we should make a new group for all the orphaned open web specs?

 -- Justin

---

From: Eran Hammer <[email-masked]>
Date: Wed, 14 Mar 2012 22:19:05 -0700

> From: Richer, Justin P. [mailto:[email-masked]]
> Sent: Wednesday, March 14, 2012 7:51 PM

> [...] the AS-PR connection is a real and present known
> gap introduced in OAuth2 (since OAuth1 didn't even think of them as
> separate entities) and *somebody* should be trying to codify the best ways
> to fill that gap and I think this is a good place to do it.

I'm not sure this is an issue for more existing implementations given that it is just an internal implementation detail. It becomes more of a use case when you have different entities managing the different roles. I'm not objecting to this line of work, but I we do need a proposal and it should be based on something more than just ideas (e.g. some deployment experience). One of the benefit of starting off a draft and not just ideas is that it shows real interest and traction.
 
> Along those lines, I don't think that SWD really belongs in the OAuth group
> either *except* for the fact that there's a Discovery mandate below that
> nobody's contesting. It's arguable that this simply covers the WWW-
> Authenticate header and its value in different contexts, but we all know this
> is incomplete discovery at best.

Discovery is a very wide topic. The only discovery item proposed I the dynamic client registration proposal. It is fine to discuss potential discovery tools in this context, but we should not be the primary source of innovation in the space. So we're in agreement that SWD doesn't belong here. Nor does WebFinger which is working on similar problems.

The ideal scenario would be to get traction on these general purpose discovery mechanisms elsewhere, and revisit this when the working group is discussing the dynamic client registration proposal. IOW, we may end up discussing and contributing to an APPS area discovery work to ensure our needs are supported, but not publish such documents in the WG.

> JWT also doesn't feel like it really belongs
> here, but since JOSE won't have it, it's a fairly important orphan that's already
> seeing deployment experience.

I don't have strong opinions on this, mostly because I understand it to be fairly finished. If the WG will need to spend a few months discussing it, I will have to reconsider.

> Add to all of this that I have two other drafts that I'd like to see dusted off
> and moved forward through some process -- alternate encoding (XML and
> Form parameters) from the token endpoint, and the UX/dynreg related
> "instance information" draft. I'll have versions of both of these uploaded
> once the IETF tracker takes the locks off at the end of the month. 

I think the XML draft is simple enough to include. I've supported it in the last round. I think the UX work is actually really important if someone is willing to take the lead on that and do the work.

> Neither of
> these saw much WG feedback or support before, though, so I'm open to
> suggestions of what a better home for them might be, if there is one. Or
> maybe we should make a new group for all the orphaned open web specs?

I think many people here don't fully understand the ways the IETF works. While working groups are the main venue for collaboration, there is a lot of work done on an Individual Submission basis (more than half?). This means a specification is created and finalized outside an official WG and without a charter.

The general mechanism (at least as used pretty effectively by me for a handful of published RFCs) is to find the right mailing list (e.g. HTTP for Link relations, Apps Discuss for host-meta and well-known, OAuth for OAuth 1.0) and support from an Area Director. You also need to fine a document shepherd  to help review and help with the "paperwork".

The way this works is that you can write a specification, discuss it on the WG list, and when you feel it is ready, ask the sponsoring AD for IETF Last Call. The AD might decide this is better suited to go through the full WG process, or feel that the document is simple and narrow enough to skip it. It is also possible that some of this work will be discussed on this list, but sponsored by an APPS area AD (e.g. the XML extension is a perfect example for something that is really not a security protocol component). So you have options.

IOW, getting your draft onto the charter is actually not always the best option for a straight-forward but low priority/interest work. The individual submission track might be better for you and the WG. You might want to reach out to one of the ADs or Chairs and discuss these options.

EH

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 15 Mar 2012 17:46:40 +0900

Looks good but I would like the group to consider the capability of signing
the request to be added.

See  http://tools.ietf.org/html/draft-sakimura-oauth-requrl-01

It basically adds capability of signing the request in the form of JWS.

=nat

On Thu, Mar 15, 2012 at 7:51 AM, Anthony Nadalin <[email-masked]>wrote:

>  ------------------------------
> From: Igor Faynberg
> Sent: 3/14/2012 4:26 PM
> To: [email-masked]
>
> authorization
> token with
> service provider
> > Apr. 2012      Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0'
> to the IESG for consideration as a Proposed Standard
> consideration as a Proposed Standard
> > May 2012    Submit 'OAuth 2.0 Threat Model and Security Considerations'
> to the IESG for consideration as an Informational RFC
> >
> > Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to the

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 15 Mar 2012 11:08:01 +0200

Hi Nat, 

We currently have 5 new items proposed for the new charter. That's quite
a lot and I expect resistance from the IESG (given our previous history
of being somewhat slow with our work). 

If you want a new item something else has to be dropped instead.
Anything you do not find as important as the draft you mention below?

Ciao
Hannes

From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Nat Sakimura
Sent: Thursday, March 15, 2012 10:47 AM
To: Anthony Nadalin
Cc: [email-masked]
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

Looks good but I would like the group to consider the capability of
signing the request to be added. 

 

=nat

On Thu, Mar 15, 2012 at 7:51 AM, Anthony Nadalin <[email-masked]>
wrote:

From: Igor Faynberg
Sent: 3/14/2012 4:26 PM
To: [email-masked]

Igor

> or even their identity. For example, a photo-sharing site that
supports
> completion of OAuth 1.0 the working group started their work on OAuth
2.0
authorization
token with
service provider
> Apr. 2012      Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth
> May 2012    Submit 'OAuth 2.0 Threat Model and Security
Considerations' to the IESG for consideration as an Informational RFC
>
> Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol' to

 

-- 
Nat Sakimura (=nat)

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 15 Mar 2012 11:10:28 +0200

Hi Mike, 

The comment I sent to Nat applies here too. Something else has to be
dropped if we add another items. 

To respond to Eran's remark I will talk to the APPs ADs to figure out
whether OAuth is the right place to do this work. There are various
considerations that matter, including 

*        In which group is the interested audience? 

*        Where is the expertise?

*        Is there a natural place the work belongs to? 

Ciao
Hannes

From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Mike Jones
Sent: Wednesday, March 14, 2012 10:55 PM
To: Hannes Tschofenig; [email-masked] WG
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

This is missing Simple Web Discovery, which there was substantial
support for including during the rechartering discussion in Taipei.
Considering OpenID Connect as a motivating use case for OAuth, SWD is
the one spec that would then be missing for this OAuth use case.

Thanks,
-- Mike

From: Hannes Tschofenig
Sent: 3/14/2012 1:21 PM
To: [email-masked] WG

So, here is a proposal:

-------

* consequently for sharing data in a security and privacy respective
way.

improvements. An extensive security analysis was conducted and the
result 

OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH
token with 
the SAML 2.0 bearer assertion profile.  This offers interworking with
existing 
identity management solutions, in particular SAML based deployments.

OAuth has enjoyed widespread adoption by the Internet application
service provider 
community. To build on this success we aim for nothing more than to make
OAuth the 
authorization framework of choice for any Internet protocol.
Consequently, the 
ongoing standardization effort within the OAuth working group is focused
on 
enhancing interoperability of OAuth deployments. While the core OAuth
specification 
truly is an important building block it relies on other specifications
in order to 
claim completeness. Luckily, these components already exist and have
been deployed 
on the Internet. Through the IETF standards process they will be
improved in 
quality and will undergo a rigorous review process. 

Goals and Milestones

Done     Submit 'OAuth 2.0 Threat Model and Security Considerations' as
a working group item
Done     Submit 'HTTP Authentication: MAC Authentication' as a working
group item
Done     Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for
consideration as a Proposed Standard
Done     Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for
consideration as a Proposed Standard

[Editor's Note: Finishing existing work. Double-check the proposed dates
- are they realistic?] 

Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for

Aug. 2012    Submit 'Token Revocation' to the IESG for consideration as
a Proposed Standard

Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for consideration
as a Proposed Standard

Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration as
an Informational RFC

---

From: Paul Madsen <[email-masked]>
Date: Thu, 15 Mar 2012 06:35:02 -0400

+1 to defining RS-AS interactions. We've implemented such a 'token 
introspection' endpoint in our AS and I'm be happy to no longer need to 
explain to customers/partners why it's not part of the standard.

As input, an (incomplete) spec for our endpoint enclosed. (we modeled 
the verification as a new grant type, leveraging as much as possible the 
existing token endpoint API)

Wrt the 5 item limit

1) is this an arbitrary #? if people sign up to work on more items, 
could it be extended?
2) the use cases document seems already well progressed (and 
informational). Need it count against the 5?

paul

---

From: John Bradley <[email-masked]>
Date: Thu, 15 Mar 2012 06:49:12 -0400

+1 to RS-AS  OpenID Connect takes a slightly different approach to Paul's.  The fact that people are reinventing the same wheel,  indicates it has standardization potential.

John B.
On 2012-03-15, at 6:35 AM, Paul Madsen wrote:

> +1 to defining RS-AS interactions. We've implemented such a 'token introspection' endpoint in our AS and I'm be happy to no longer need to explain to customers/partners why it's not part of the standard.
> 
> As input, an (incomplete) spec for our endpoint enclosed. (we modeled the verification as a new grant type, leveraging as much as possible the existing token endpoint API)
> 
> Wrt the 5 item limit
> 
> 1) is this an arbitrary #? if people sign up to work on more items, could it be extended?
> 2) the use cases document seems already well progressed (and informational). Need it count against the 5?
> 
> paul
> 
> <ping-oauth-verification-01.txt>_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Paul Madsen <[email-masked]>
Date: Thu, 15 Mar 2012 07:04:00 -0400

To Eran's point about the relevance of RS-AS standardization in internal 
vs external deployments, many of our customers are using our AS to issue 
tokens to their API clients, but an API management solution (from 
different vendor) to front their APIs.

The API management soln becomes the RS and must validate the tokens it 
sees against our AS.

Until OAuth standardizes this piece, we have to convince such partners 
to use our (necessarily proprietary) endpoint (or support whatever 
mechanism they expect).

paul

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 15 Mar 2012 13:12:56 +0200

Hi Paul, 

Interesting stuff. Thanks for sharing your draft writeup with us. 

Could you submit the document as Internet Draft when the submission
gates open again? 

The I-D submission tool will be reopened at 00h UTC, 2012-03-26.

>From the current list of items what do you consider less important?

Ciao

Hannes

From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Paul Madsen
Sent: Thursday, March 15, 2012 12:35 PM
To: Richer, Justin P.
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

Wrt the 5 item limit

paul

 
Proposals for inclusion in the discussion include UMA's Step 3, OpenID
Connect's CheckID, and several "token introspection" endpoints in
various implementations.
 
 -- Justin

	So, here is a proposal:
	 
	-------

	 
	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 
	sharing his or her photo-sharing sites' long-term credential
with the 
	printing site. 
	 
	The OAuth protocol suite encompasses
	* a procedure for allowing a client to discover a resource
server, 
	* a protocol for obtaining authorization tokens from an
authorization 
	server with the resource owner's consent, 
	* protocols for presenting these authorization tokens to
protected 
	resources for access to a resource, and 
	* consequently for sharing data in a security and privacy
respective way.
	 
	In April 2010 the OAuth 1.0 specification, documenting pre-IETF
work,
	was published as an informational document (RFC 5849). With the 
	completion of OAuth 1.0 the working group started their work on
OAuth 2.0
	to incorporate implementation experience with version 1.0,
additional
	use cases, and various other security, readability, and
interoperability
	improvements. An extensive security analysis was conducted and
the result 
	is available as a stand-alone document offering guidance for
audiences 
	beyond the community of protocol implementers.
	 
	The working group also developed security schemes for presenting
authorization
	tokens to access a protected resource. This led to the
publication of
	the bearer token as well as the message authentication code
(MAC) access 
	authentication specification. 
	 
	OAuth 2.0 added the ability to trade a SAML assertion against an
OAUTH token with 
	the SAML 2.0 bearer assertion profile.  This offers interworking
with existing 
	identity management solutions, in particular SAML based
deployments.
	 
	OAuth has enjoyed widespread adoption by the Internet
application service provider 
	community. To build on this success we aim for nothing more than
to make OAuth the 
	authorization framework of choice for any Internet protocol.
Consequently, the 
	ongoing standardization effort within the OAuth working group is
focused on 
	enhancing interoperability of OAuth deployments. While the core
OAuth specification 
	truly is an important building block it relies on other
specifications in order to 
	claim completeness. Luckily, these components already exist and
have been deployed 
	on the Internet. Through the IETF standards process they will be
improved in 
	quality and will undergo a rigorous review process. 
	 
	Goals and Milestones

	Done     Submit 'OAuth 2.0 Threat Model and Security
Considerations' as a working group item
	Done     Submit 'HTTP Authentication: MAC Authentication' as a
working group item
	Done     Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the
IESG for consideration as a Proposed Standard
	Done     Submit 'The OAuth 2.0 Authorization Protocol' to the
IESG for consideration as a Proposed Standard
	 
	[Editor's Note: Finishing existing work. Double-check the
proposed dates - are they realistic?] 
	 
	Jun. 2012       Submit 'HTTP Authentication: MAC Authentication'
to the IESG for consideration as a Proposed Standard
	Apr. 2012       Submit 'SAML 2.0 Bearer Assertion Profiles for
OAuth 2.0' to the IESG for consideration as a Proposed Standard
	Apr. 2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for
consideration as a Proposed Standard 
	Apr. 2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the
IESG for consideration as a Proposed Standard 
	May 2012    Submit 'OAuth 2.0 Threat Model and Security
Considerations' to the IESG for consideration as an Informational RFC

	Aug. 2012    Submit 'Token Revocation' to the IESG for
consideration as a Proposed Standard

	Nov. 2012    Submit 'JSON Web Token (JWT)' to the IESG for
consideration as a Proposed Standard

	Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles
for OAuth 2.0' to the IESG for consideration as a Proposed Standard

	Jan. 2013    Submit 'OAuth Dynamic Client Registration Protocol'
to the IESG for consideration as a Proposed Standard

	Sep. 2012    Submit 'OAuth Use Cases' to the IESG for
consideration as an Informational RFC

---

From: John Bradley <[email-masked]>
Date: Thu, 15 Mar 2012 07:26:09 -0400

In Connect it is mostly the client that introspects the token, though we do use JWT to keep things stateless.

As we move to more complex environments where clients are getting multiple tokens from a AS for RS and those RS are decoupled from the AS,  we need to talk about JWT and introspection.

They will become blocking issues for interoperability at larger scale.

John B.
On 2012-03-15, at 7:04 AM, Paul Madsen wrote:

> To Eran's point about the relevance of RS-AS standardization in internal vs external deployments, many of our customers are using our AS to issue tokens to their API clients, but an API management solution (from different vendor) to front their APIs. 
> 
> The API management soln becomes the RS and must validate the tokens it sees against our AS. 
> 
> Until OAuth standardizes this piece, we have to convince such partners to use our (necessarily proprietary) endpoint (or support whatever mechanism they expect).
> 
> paul
>

---

From: Blaine Cook <[email-masked]>
Date: Thu, 15 Mar 2012 11:31:17 +0000

On 14 March 2012 20:21, Hannes Tschofenig <[email-masked]> wrote:
> Nov. 2012    Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration

This looks great to me.

I have serious concerns about feature-creep, and think that the OAuth
WG should strongly limit its purview to these issues. In general, I
think it prudent for this working group in particular to consider
standardisation of work only under the following criteria:

1. Proposals must have a direct relationship to the mechanism of OAuth
(and not, specifically, bound to an application-level protocol).
2. Proposals must have significant adoption in both enterprise and
startup environments.
3. Any proposal must be driven based on a consideration of the
different approaches, as adopted in the wild, and strive to be a
better synthesis of those approaches, not a means to an end.

These are the constraints with which I started the OAuth project, and
they're more relevant than ever. I'd hate to see OAuth fail in the end
because of a WS-*-like death by standards-pile-on.

b.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 15 Mar 2012 13:46:34 +0200

Hi Blaine, 

These are indeed good requirements you stated below. 

When you look at the list of topics do you think that the proposed items indeed fulfill them? 

Ciao
Hannes

> Of ext Blaine Cook
> Sent: Thursday, March 15, 2012 1:31 PM
> To: Hannes Tschofenig
> Cc: [email-masked] WG
> OAuth 2.0' to the IESG for consideration

---

From: Paul Madsen <[email-masked]>
Date: Thu, 15 Mar 2012 08:10:31 -0400

Hi Hannes, happy to submit as ID once possible.

Wrt the current 5, we want them all (and more) :-) but the following are 
data points for our prioritization

0) JWT is a given

1) we have implemented the SAML bearer token profile, somewhat 
deprioritizing for us in the immediate term the equivalent JWT profile 
(but not the long term)

2) customers are demanding programmatic client registration. For one 
customer, the use case is to allow clients to be added to our AS via an 
API management solution. The customer wants client developers to use the 
API management tool as the single touch point into their APIs - adding 
clients, being issued credentials etc

As well, the TV Everywhere driven OATC spec (based on OAuth 2) has 
requirements for the same

3) as valuable as an informational use cases discussion will be, I'd 
hope it doesnt prevent us tackling normative work

4) wrt revocation, we definitely see use cases  (enterprise employee is 
issued long lived refresh token for a mobile SaaS app, then gets fired 
and so enterprise needs to turn off the access) but can probably achieve 
the equivalent with a SCIM 'delete user' message

paul

On 3/15/12 7:12 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *ext Paul Madsen
> *Sent:* Thursday, March 15, 2012 12:35 PM
> *To:* Richer, Justin P.
> *Cc:* [email-masked] WG
> *Subject:* Re: [OAUTH-WG] OAuth WG Re-Chartering
>
> introspection' endpoint in our AS and I'm be happy to no longer need 
> to explain to customers/partners why it's not part of the standard.
>
> the verification as a new grant type, leveraging as much as possible 
> the existing token endpoint API)
>
> Wrt the 5 item limit
>
>     [Starting point for the work will behttp://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]
>
>       
>
>     [Starting point for the work will behttp://tools.ietf.org/html/draft-jones-json-web-token]
>
>       
>
>     [Starting point for the work will behttp://tools.ietf.org/html/draft-jones-oauth-jwt-bearer]
>
>       
>
>     [Starting point for the work will behttp://tools.ietf.org/html/draft-hardjono-oauth-dynreg]
>
>       
>
>     [Starting point for the work will behttp://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]
>
>       
>
>       
>
>       
>
>     [email-masked]  <mailto:[email-masked]>
>
> [email-masked]  <mailto:[email-masked]>

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 15 Mar 2012 13:22:24 +0000

4) wrt revocation, we definitely see use cases  (enterprise employee is issued long lived refresh token for a mobile SaaS app, then gets fired and so enterprise needs to turn off the access) but can probably achieve the equivalent with a SCIM 'delete user' message

Token revocation and user deletion are completely separate issues -- there's no real overlap here. It's about closing the session management gap (for both access and refresh tokens) and it has nothing to do with deprovisioning a user in a system. In many cases, there might not even be a "user" that the token directly represents, or the client wouldn't know enough about them to make a delete user message. And that's a very good thing -- Would you really want to give every delegated client the ability to delete your account when it felt like it? Absolutely not - that level of power is completely counter to the whole point of delegated access.

Plus, for what it's worth, it's pretty much finished already and we've implemented the endpoint already, too.

To answer Hannes's original question, I think the WG's priorities from the list ought to be, in rough order:

1) Revocation (for reasons above)
2) Dynamic Registration (big need for this and several drafts already out there to start from)
3) JWT Bearer (it matches the profile for saml bearer and fits in the OAuth world well)
4) JWT, if no one else will take it (and it is basically done, and well deployed already)
5) Use cases (since it's informational and bound to cause some level of controversy, I wouldn't want to see this really detract from the real normative standards work, and don't think it should be counted against the total)

For other documents discussed, like XML encoding, SWD, UX, and things like that, other avenues *may* be a better fit and I'm happy with pursuing some of these myself. But with so much of the work on these and other documents already done, many of the same arguments for inclusion of the above five apply.

 -- Justin

Could you submit the document as Internet Draft when the submission gates open again?
The I-D submission tool will be reopened at 00h UTC, 2012-03-26.

Ciao
Hannes

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext Paul Madsen
Sent: Thursday, March 15, 2012 12:35 PM
To: Richer, Justin P.
Cc: [email-masked]<mailto:[email-masked]> WG
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

Wrt the 5 item limit

paul

 -- Justin

So, here is a proposal:

-------

printing site.

Goals and Milestones

OAuth mailing list

OAuth mailing list

---

From: Paul Madsen <[email-masked]>
Date: Thu, 15 Mar 2012 09:54:36 -0400

Agree that they are separate. For the use case I gave the fundamental requi

Sent from my iPhone

On 2012-03-15, at 9:22 AM, "Richer, Justin P." <[email-masked]> wrote:

>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Paul Madsen

---

From: Eran Hammer <[email-masked]>
Date: Thu, 15 Mar 2012 08:00:11 -0700

I believe most do, except for the dynamic client registration. I don't have strong objections to it, but it is the least important and least defined / deployed proposal on the list. The AS->RS work is probably simpler and more useful at this point.

EH

> Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Thursday, March 15, 2012 4:47 AM
> To: ext Blaine Cook; Hannes Tschofenig
> Cc: [email-masked]
> > On 14 March 2012 20:21, Hannes Tschofenig
> <[email-masked]>
> > wrote:
> > > So, here is a proposal:
> > >

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Thu, 15 Mar 2012 12:31:47 -0500

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, March 14, 2012 4:55 PM
To: Hannes Tschofenig; [email-masked] WG
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

...  Considering OpenID Connect as a motivating use case for OAuth, SWD is the one spec that would then be missing for this OAuth use case.

...

Mike,

I will be happy to work with you on the OpenID Connect use case.  We could probably submit it as a separate I-D and later include it in the Use Case document.  I agree with with you  that this is an important use case, and it ought to be there independent of where the SWD work is done; in other words, I think that we just need the use case description at this point (including, pre- and post conditions)-not the requirements or the list of dependencies.

Zachary

---

From: Blaine Cook <[email-masked]>
Date: Mon, 19 Mar 2012 15:24:23 +0000

On 15 March 2012 17:31, Zeltsan, Zachary (Zachary)
<[email-masked]> wrote:
> ...  Considering OpenID Connect as a motivating use case for OAuth, SWD is

I worry that bringing OpenID Connect into OAuth (rather than building
upon OAuth) will have detrimental effects for both efforts. OAuth is
successful in part because we chose not to push OAuth-like
functionality into the OpenID umbrella (which at the time was focused
on shipping OpenID 2.0).

It seems prudent to learn from the experience of WS-*, where
everything was combined into one huge ball of standards-wax. The
result was both impenetrable and not fit for purpose due to the many
interdependencies (both social and technical) involved.

Composition has served the IETF and the internet well, and nothing
prevents the OpenID standards from being created in the context of a
new working group, or from within the OpenID foundation. Indeed, it's
been working quite well, and projects like the Account Chooser are
showing great promise and focusing on the important things (UX) rather
than specifications-for-specification's sake.

b.

---

From: John Bradley <[email-masked]>
Date: Mon, 19 Mar 2012 13:31:26 -0300

There is not intention to bring the openID Connect work to the OAuth WG.
It like many other protocols rely on OAuth 2.0 but are not part of it.

However if there are some things that we are doing as OAuth 2.0 extensions
that are more general and can be standardized in the IETF, we should understand 
what they are.  

We are having a openID Connect meeting on Sunday prior to IETF.
People are encouraged to attend and refine opinions about the appropriate homes
for some of this new(to IETF) work.

Registration is at:
http://www.eventbrite.com/event/3064019565

The account chooser WG that Blaine mentioned at OIDF is up and running now, with a online meeting happening 
Thursday for those that are interested.
https://sites.google.com/site/oidfacwg/
http://acwg2012march-estw.eventbrite.com

So +1 for composition.

John B.

---

From: Phil Hunt <[email-masked]>
Date: Mon, 19 Mar 2012 10:30:51 -0700

I would support those features of connect that are more general being part of the general spec family under the WG. 

Phil

---

From: John Bradley <[email-masked]>
Date: Mon, 19 Mar 2012 14:52:25 -0300

JWT and SWD are the highest priority to find a home.   

We are doing token introspection and dynamic registration.
Those are larger tasks to generalize, though probably worthwhile.

John B.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 21 Mar 2012 20:33:40 +0100

Hi Paul,

for me, your proposal looks like the natural counterpart of JWT, as it 
standardizes the way to implement handle-based token designs (in 
contrast to self-contained tokens).

therefore +1 from my side.

regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 21 Mar 2012 20:35:58 +0100

In my opinion, dynamic client registration would allow us to drop public 
client thus simplifying the core spec.

regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 21 Mar 2012 20:40:43 +0100

Hi Hannes,

+1

You have compiled a list of meaningful and feasible objectives.

regards,
Torsten.

---

From: John Bradley <[email-masked]>
Date: Wed, 21 Mar 2012 16:52:34 -0300

I don't think dynamic registration completely removes the need for a public client, that can't keep secrets.

While we did do dynamic client registration for Connect that is a more constrained use case.
I would put JWT and AS-RS communication as higher priorities than dynamic registration.
Partially because they are more self contained issues.

John B.
On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote:

> In my opinion, dynamic client registration would allow us to drop public client thus simplifying the core spec.
> 
> regards,
> Torsten.
>

---

From: Eran Hammer <[email-masked]>
Date: Wed, 21 Mar 2012 13:35:24 -0700

As a general rule, we should not add any item to the charter unless there is a well-reviewed (and well-received) draft available as the basis for future work, as well as at least one editor for the task.

EH

> From: John Bradley [mailto:[email-masked]]
> Sent: Wednesday, March 21, 2012 12:53 PM
> To: Torsten Lodderstedt
> Cc: Eran Hammer; [email-masked]
> >> I believe most do, except for the dynamic client registration. I don't have
> strong objections to it, but it is the least important and least defined /
> deployed proposal on the list. The AS->RS work is probably simpler and more
> useful at this point.
> >>
> >> EH
> >>

---

From: George Fletcher <[email-masked]>
Date: Wed, 21 Mar 2012 16:50:42 -0400

+1 to JWT and AS-RS communication over dynamic registration

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 22 Mar 2012 09:29:43 +0100

Hi John,

> public client, that can't keep secrets.

I don't get this argument. In my opinion, there are two use cases, 
which currently motivate usage of public clients and none of them is 
about "keeping secrets".

1) native apps - There is no mechanism for securely _provisioning_ 
those clients with client secrets. So it does not make sense to use 
secrets for authenticating them. Dynamic client registration would allow 
them to obtain client id and secret on activation/installation. The 
security of the respective secret is the same as for refresh tokens. So 
either both can be protected appropriately or none of them. Please note: 
I'm not talking about trust in the identity/authenticity of the 
particular app installation. I'm just talking about simplifying the 
OAuth flows and description. Today an AS needs to support the refresh 
tokens or resource owner grant type for both confidential and public 
clients in order to also support native apps.
2) implicit grant - here, public clients are used because the protocol 
design itself does not allows for validating client secrets. Obviously, 
digital signature would help but make the protocol more difficult to 
use.

Basically, dynamic client registration allows a client to bind to an AS 
at runtime. That's what it makes so valuable with respect to 
interoperatibility. Whether the client just registers meta data or also 
obtains a secret is another aspect but not the only one.

regards,
Torsten.

>> In my opinion, dynamic client registration would allow us to drop 
>> public client thus simplifying the core spec.
>>
>> regards,
>> Torsten.
>>
>>> I believe most do, except for the dynamic client registration. I 
>>> don't have strong objections to it, but it is the least important and 
>>> least defined / deployed proposal on the list. The AS->RS work is 
>>> probably simpler and more useful at this point.
>>>
>>> EH
>>>
>>>> When you look at the list of topics do you think that the proposed 
>>>> items
>>>> indeed fulfill them?
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>>
>>>>>> for

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 22 Mar 2012 09:40:09 +0100

Hi George, 

I see two distinct areas of interoperability, which
are Client-AS and AS-RS. Dynamic client registration belongs to
Client-AS whereas JWT & AS-RS communication belong to the later area.

OAuth 2.0 currently (not fully) covers Client-AS and does not address
AS-RS. In my opinion, the WG should decide whether we first complete
Client-AS and address AS-RS later on or vice versa. 

I'm in favour of
completing Client-AS first and consider client registration a major
missing piece. Why? Because otherwise clients cannot dynamically bind to
any OAuth-AS at runtime but have to pre-register (with any?) :-(.

regards,
Torsten. 

Am 21.03.2012 21:50, schrieb George Fletcher: 

>> I don't think dynamic
registration completely removes the need for a public client, that can't
keep secrets.
>> 
>> While we did do dynamic client registration for
Connect that is a more constrained use case.
>> I would put JWT and
AS-RS communication as higher priorities than dynamic registration.
On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote:
>>> In my
opinion, dynamic client registration would allow us to drop public
client thus simplifying the core spec.
Torsten.
>>>> I
believe most do, except for the dynamic client registration. I don't
have strong objections to it, but it is the least important and least
defined / deployed proposal on the list. The AS->RS work is probably
simpler and more useful at this point.
-----Original Message-----
>>>>> From: [email-masked] [6]
[mailto:[email-masked] [7]] On Behalf
>>>>> To: ext Blaine Cook; Hannes Tschofenig
[8]
>>>>> Hi
Blaine,
>>>>> When you look at the list of topics do you think
that the proposed items
Ciao
>>>>>> From:
[email-masked] [1] [mailto:[email-masked] [2]] On
Behalf
>>>>>> Cc: [email-masked] [3]
WG

>>>>>>> Aug. 2012 Submit
'Token Revocation' to the IESG for consideration
>>>>>> as a
Proposed Standard
>>>>>>> 2.0' to the IESG for consideration
>>>>>>
er-left:#1010ff 2px solid; margin-left:5px; width:100%"> 

>>>>>> the IESG for considerat> solid; margin-left:5px; width:100%">

>>>>>>> 
>>>>>>> Sep. 2012 Submit 'OAuth Use Cases' to
>>>>>>
consideration 
>>>>>> as an Informational RFC
This looks great to me.
>>>>>> WG should strongly limit
its purview to these issues. > y under the following criteria: 1.
Proposals must have a direct relationship to t
>>>>>> of OAuth (and not,
specifically, bound to an application-level protocol). 2. Proposals must
have significant adoption in both enterprise and startup environments.
3. Any proposal must be driven based on a consideration of the different
approaches, as adopted in the wild, and strive to be a better synthesis
of those approaches, not a means to an end. These are the constraints
with which I started the OAuth project, and they're more relevant than
ever. I'd hate to see OAuth fail in the end because of a WS-*-like death
by standards-pile-on. b. _______________________________________________
OAuth mailing list [email-masked] [4]
https://www.ietf.org/mailman/listinfo/oauth [5]
>>>>> OAuth mailing
list
>>>>> [email-masked] [9]
https://www.ietf.org/mailman/listinfo/oauth [10]
>>>> OAuth mailing
list
>>>> [email-masked] [11]
https://www.ietf.org/mailman/listinfo/oauth [12]
>>> OAuth mailing
list
>>> [email-masked] [13]
https://www.ietf.org/mailman/listinfo/oauth [14]
>> OAuth mailing list
[email-masked] [15]
>> https://www.ietf.org/mailman/listinfo/oauth
[16]

Links:
------
[1] mailto:[email-masked]
[2]
mailto:[email-masked]
[3] mailto:[email-masked]
[4]
mailto:[email-masked]
[5]
https://www.ietf.org/mailman/listinfo/oauth
[6]
mailto:[email-masked]
[7] mailto:[email-masked]
[8]
mailto:[email-masked]
[9] mailto:[email-masked]
[10]
https://www.ietf.org/mailman/listinfo/oauth
[11]
mailto:[email-masked]
[12]
https://www.ietf.org/mailman/listinfo/oauth
[13]
mailto:[email-masked]
[14]
https://www.ietf.org/mailman/listinfo/oauth
[15]
mailto:[email-masked]
[16] https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Thu, 22 Mar 2012 10:24:35 -0300

In Connect's dynamic client authentication we optionally allow for authenticated clients to register.

The idea is that you can have a master token pre provisioned in an app and then use that to get an individual client ID and client secret for a native app on a per instance basis.
This is useful to UMA, and potentially other cases where de-authorizing a particular instance of a client from using it's refresh token would be useful.

So I agree that obtaining a clientID and secret on activation is useful.

While you could theoretically move JS clients who are public now to a registration and code flow it is unclear to me if that actually adds any real security.  
I can see a simplification of the AS argument,  but at a performance cost to the client.

As to the refresh token argument, it seems that Facebook at least has moved to refreshing access tokens directly to get around the implicit grant problem.

I am for Dynamic client registration, I just don't think it is a silver bullet, and needs significant thought.

I admit that openID is not under time pressure on this as we have our own extension,  that is not intended to be generic.
However we did make registration a separate spec so that people can reuse the pattern if it works for them, but mostly to make it easier for us to move to a eventual standard without modifying the core spec.

John B.

On 2012-03-22, at 5:29 AM, Torsten Lodderstedt wrote:

> I don't get this argument. In my opinion, there are two use cases, which currently motivate usage of public clients and none of them is about "keeping secrets".
> 
> 1) native apps - There is no mechanism for securely _provisioning_ those clients with client secrets. So it does not make sense to use secrets for authenticating them. Dynamic client registration would allow them to obtain client id and secret on activation/installation. The security of the respective secret is the same as for refresh tokens. So either both can be protected appropriately or none of them. Please note: I'm not talking about trust in the identity/authenticity of the particular app installation. I'm just talking about simplifying the OAuth flows and description. Today an AS needs to support the refresh tokens or resource owner grant type for both confidential and public clients in order to also support native apps.
> 2) implicit grant - here, public clients are used because the protocol design itself does not allows for validating client secrets. Obviously, digital signature would help but make the protocol more difficult to use.
> 
> Basically, dynamic client registration allows a client to bind to an AS at runtime. That's what it makes so valuable with respect to interoperatibility. Whether the client just registers meta data or also obtains a secret is another aspect but not the only one.
> 
> regards,
> Torsten.
> 
>>

---

From: George Fletcher <[email-masked]>
Date: Thu, 22 Mar 2012 09:28:16 -0400

Hi Torsten,

I guess I worry that trying to solve all the use cases that get pulled 
in with dynamic client registration will take a long time. I've been 
involved with both the UMA work and the OpenID Connect work regarding 
dynamic client registration and some reasonable constraints and 
expectations need to be set in order to reach consensus.

And what John said... since he beat my response:)

Thanks,
George

On 3/22/12 4:40 AM, Torsten Lodderstedt wrote:
>
> Hi George,
>
> I see two distinct areas of interoperability, which are Client-AS and 
> AS-RS. Dynamic client registration belongs to Client-AS whereas JWT & 
> AS-RS communication belong to the later area.
>
> I'm in favour of completing Client-AS first and consider client 
> registration a major missing piece. Why? Because otherwise clients 
> cannot dynamically bind to any OAuth-AS at runtime but have to 
> pre-register (with any?) :-(.
>
> regards,
> Torsten.
>
>>>>>> From:[email-masked]  [mailto:[email-masked]] On Behalf
>>>>>> Cc:[email-masked]
>>>>>>> From:[email-masked]  [mailto:[email-masked]] On Behalf
>>>>>>> Of ext Blaine Cook
>>>>>>> Cc:[email-masked]  WG

---

From: Mike Jones <[email-masked]>
Date: Thu, 22 Mar 2012 15:34:54 +0000

FYI, the OpenID Connect dynamic client registration spec is at http://openid.net/specs/openid-connect-registration-1_0.html.  You can find points to all the Connect specs at http://openid.net/connect/.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of George Fletcher
Sent: Thursday, March 22, 2012 6:28 AM
To: Torsten Lodderstedt
Cc: [email-masked]
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

Hi Torsten,

I guess I worry that trying to solve all the use cases that get pulled in with dynamic client registration will take a long time. I've been involved with both the UMA work and the OpenID Connect work regarding dynamic client registration and some reasonable constraints and expectations need to be set in order to reach consensus.

Thanks,
George

Hi George,

I see two distinct areas of interoperability, which are Client-AS and AS-RS. Dynamic client registration belongs to Client-AS whereas JWT & AS-RS communication belong to the later area.

OAuth 2.0 currently (not fully) covers Client-AS and does not address AS-RS. In my opinion, the WG should decide whether we first complete Client-AS and address AS-RS later on or vice versa.

I'm in favour of completing Client-AS first and consider client registration a major missing piece. Why? Because otherwise clients cannot dynamically bind to any OAuth-AS at runtime but have to pre-register (with any?) :-(.

regards,
Torsten.

John B.

regards,

Torsten.

EH

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf

Cc: [email-masked]<mailto:[email-masked]>

Hi Blaine,

When you look at the list of topics do you think that the proposed items

indeed fulfill them?

Ciao

Hannes

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf

Of ext Blaine Cook

To: Hannes Tschofenig

wrote:

So, here is a proposal:

Aug. 2012    Submit 'Token Revocation' to the IESG for consideration

as a Proposed Standard

Sep. 2012    Submit 'OAuth Use Cases' to the IESG for consideration

as an Informational RFC

This looks great to me.

startup environments.

b.

OAuth mailing list

OAuth mailing list

OAuth mailing list

OAuth mailing list

OAuth mailing list

---

From: Phil Hunt <[email-masked]>
Date: Thu, 22 Mar 2012 09:24:37 -0700

Would the plan be for the Connect Registration spec to be submitted to IETF so they can become WG drafts?

The spec seems like a good starting point.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Eran Hammer <[email-masked]>
Date: Thu, 22 Mar 2012 09:34:24 -0700

I really like the 5 items limit. If people are uncomfortable about leaving so many items off the charter, the charter can have an explicit line item for further charter review once all work has been completed. This is the default process anyway, but people here tend to be over sensitive, you that's one way to address that concern.

Any item proposed must be supported by an existing I-D used as the basis for WG work, at least one editor with the capacity to see this work through, and sufficient WG interest to do the work. It must also be 100% relevant to OAuth and belong in a security area working group.

I strongly believe that suggesting charter items without an existing draft is counter productive. If the work exists elsewhere, it must first be submitted as an I-D before we discuss it.

EH

From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: Thu, 22 Mar 2012 09:24:37 -0700
To: Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of George Fletcher
Sent: Thursday, March 22, 2012 6:28 AM
To: Torsten Lodderstedt
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering

Hi Torsten,

Thanks,
George

Hi George,

regards,
Torsten.

John B.

regards,

Torsten.

EH

-----Original Message-----

Hi Blaine,

indeed fulfill them?

Ciao

Hannes

-----Original Message-----

Of ext Blaine Cook

To: Hannes Tschofenig

wrote:

So, here is a proposal:

as a Proposed Standard

as an Informational RFC

This looks great to me.

startup environments.

b.

OAuth mailing list

OAuth mailing list

OAuth mailing list

OAuth mailing list

OAuth mailing list

---

From: John Bradley <[email-masked]>
Date: Thu, 22 Mar 2012 13:43:36 -0300

It is a OIDF spec at the moment.  We don't have any plan to submit it currently.  

If there is a WG desire for that to happen the OIDF board would have to discuss making a submission.

All in all I don't know that it is worth the IPR Lawyer time, as Thomas has a quite similar ID Submission.

Anything is possible however.   

John B.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 22 Mar 2012 10:24:24 -0700

I've been told recently that they have to be published as I-Ds to be considered.  The secretariat even clamped down on referencing external blog posts never-mind external specs. :-)  The new SCIM BoF which hopes to get a WG formed had to arrange to get the simplecloud.info specs submitted as I-Ds requiring the AD had to open a special window to allow the specs to be submitted during the closed period (which re-opens Mar 26).

I think dynamic registration should become part of the IETF (as opposed to OIDF) because there is a broad issue with software that is installed in many locations running the same service APIs that clients can reach. The OpenID Connect scenario demonstrates one possible case of many to come - particularly with the same software running in the cloud and private infrastructure. 

SCIM (simplecloud.info) is another example. Not only did they have the same IPR issue, but they have the same dynamic registration issue since the idea is that application service providers implement a common RESTful service API for provisioning.

I suspect that since the OIDF would have to decide this, it might not be able to happen in time for the charter. I support this happening after, as long as it is fairly soon --> I have to agree with Eran's practical assertion that charter items should be supported by an existing I-D as a starting point.

Phil

@independentid
www.independentid.com
[email-masked]