Subject: Re: [OAUTH-WG] New Working Group Items?

From: Kristoffer Gronowski <[email-masked]>
Date: Mon, 7 Feb 2011 16:10:58 -0500

Hi Torsten!

Great that you compiled the list on WG items.
IMO there is one item missing and that is to create an optional formal interface between the authorization server and the protected resource.
It could increase the productivity of creating the oauth protected web services when the auth server can be treated as an off the shelf piece of code.
Then it would be up to the auth server to also provide an number of other extension like the discovery, token revocation and other.

The next most important for me is the discovery but here I would rather want to tie on to existing technologies that already describe REST resources like WADL.
So that the Oauth discovery metadata just deals with two levels of metadata. First being more static information about the oauth server that is authorative over the protected resource.
Second would be the endpoint specific authorization data about the resource what kind of scopes are required for me to fulfill a successful request. But here it needs to be more innovative since it might be a different answer if I am trying to do a HTTP GET then what would be needed if I am trying to do a HTTP DELETE request on a protected resource.

We are actually trying to experiment with the two different API for auth server <-> protected resource IF and for resource discovery to get hands on experience on how they could look like.
So if other sees the same value we would be happy to collaborate and try to contribute it becoming something agreed upon within this WG.
The good part is that all of our experiments are shared in open source so others could also join in and we do not have any strong opinion that it has to be solved our way.

BR Kristoffer

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 07 Feb 2011 22:14:19 +0100

Hi Kristoffer,

Hannes compiled the list :-)

regards,
Torsten.

Am 07.02.2011 22:10, schrieb Kristoffer Gronowski:
> IMO there is one item missing and that is to create an optional formal 
> interface between the authorization server and the protected resource.
> It could increase the productivity of creating the oauth protected web 
> services when the auth server can be treated as an off the shelf piece 
> of code.
> Then it would be up to the auth server to also provide an number of 
> other extension like the discovery, token revocation and other.
> The next most important for me is the discovery but here I would 
> rather want to tie on to existing technologies that already describe 
> REST resources like WADL.
> So that the Oauth discovery metadata just deals with two levels of 
> metadata. First being more static information about the oauth server 
> that is authorative over the protected resource.
> Second would be the endpoint specific authorization data about the 
> resource what kind of scopes are required for me to fulfill a 
> successful request. But here it needs to be more innovative since it 
> might be a different answer if I am trying to do a HTTP GET then what 
> would be needed if I am trying to do a HTTP DELETE request on a 
> protected resource.
> We are actually trying to experiment with the two different API for 
> auth server <-> protected resource IF and for resource discovery to 
> get hands on experience on how they could look like.
> So if other sees the same value we would be happy to collaborate and 
> try to contribute it becoming something agreed upon within this WG.
> The good part is that all of our experiments are shared in open source 
> so others could also join in and we do not have any strong opinion 
> that it has to be solved our way.
> BR Kristoffer
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Kristoffer Gronowski <[email-masked]>
Date: Mon, 7 Feb 2011 16:19:25 -0500

Oops, sorry did not want to steal anyone's thunder!
Just a honest indentation mistake, great list Hannes.

BR Kristoffer

________________________________
From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Monday, February 07, 2011 1:14 PM
To: Kristoffer Gronowski
Cc: [email-masked]
Subject: Re: [OAUTH-WG] New Working Group Items?

Hi Kristoffer,

regards,
Torsten.

BR Kristoffer

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

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 07 Feb 2011 20:20:57 -0500

Kristoffer,

I assume you mean an interface between the authorization server and the 
resource server. If so, I believe it definitely merits a serious 
discussion, and I support the idea in principle.

On this subject, I think we need even more work defining the token and 
linking it to the resource owner.  Today's discussion between Eran and 
Phil once again made me think of insufficiency of the "opaque tokens." 
Indeed, anything that comes with the OAuth flow is an OAuth token. (From 
the security point of view, of course, that also means that anything 
that can be INSERTED into an OAuth flow will be an OAuth token...)  I am 
not criticizing  the  design decisions--I have  agreed with all of them.

But going forward, I would like the resource owner, the end user (both 
human and virtual) to 1) issue tokens or 2) outsource this work it it 
wishes. In the latter case, the resource owner must at least understand 
what the token has rather than just pass the token.

Ideally, I would like this to be an OAuth work item: OAuth WG works very 
well, and it has gathered the best people to judge the task. I 
understand though that token specification is not presently in the 
charter, and therefore it can be discussed only in the context of 
changing the charter. And so I first wrote this in response to the item 
that you proposed, which I think is one step toward what I thought 
should be done.

Igor

Kristoffer Gronowski wrote:
> ...

---

From: Kristoffer Gronowski <[email-masked]>
Date: Mon, 7 Feb 2011 21:26:09 -0500

Hi Igor!

That is exactly what I would like to explore!
My thinking was that the authorization server should be quite simple.
There should be no advanced things like a policy server inside it.

As long as the authorization (AS) and the resource servers (RS) use the same identity source (or trusted federation of it).
I was thinking of a simple interface that can work in layers.
1) The RS can ask the AS is this a valid token yes/no
2) Is this a valid token containing the following scopes?
3) Was this a token issued by a particular user X. (Based on sharing or trusting in the identity source)

Or a combination of the above. In this way you can at least do a good separation of concerns.
Except of the answer if the criteria was met I have been experimenting also in returning metadata from the AS so that a RS interceptor can be built.
You would get all data about token lifetime, scopes attached and owner information.
This would be a combination with the request input parameters. So you can start off with making sure that #1 is valid.
Since the token needs to have been generated by the AS.
Then if you have a more dynamic policy that is very endpoint specific it is far easier to implement it in code then in a general purpose policy server.

Then you can easily implement things like this protected resource needs scope X or Y Mon-Fri while Z on weekends.
Another advantage is that the same code can work on your behalf in discovery mode to actually give you a clue what is needed at this very moment to access.
The AS is just following strict rules and giving facts to you as a RS.

It is a pretty clean design but I am sure that it will not fit everyone's needs.
And I am not saying that policy server would go away but for simple REST services this is a powerful framework where you do not have to mash all of you implementation into one big thing.

So that it why I was thinking that it might be a candidate for an optional interface that might be good to have.
With it people can develop Oauth protected services quicker since there is more ready code to start from.

Does this still fit your vision too described this way?

BR Kristoffer  

-----Original Message-----
From: Igor Faynberg [mailto:[email-masked]] 
Sent: Monday, February 07, 2011 5:21 PM
To: Kristoffer Gronowski
Cc: [email-masked]
Subject: Re: [OAUTH-WG] New Working Group Items?

Kristoffer,

I assume you mean an interface between the authorization server and the resource server. If so, I believe it definitely merits a serious discussion, and I support the idea in principle.

On this subject, I think we need even more work defining the token and linking it to the resource owner.  Today's discussion between Eran and Phil once again made me think of insufficiency of the "opaque tokens." 
Indeed, anything that comes with the OAuth flow is an OAuth token. (From the security point of view, of course, that also means that anything that can be INSERTED into an OAuth flow will be an OAuth token...)  I am not criticizing  the  design decisions--I have  agreed with all of them.

But going forward, I would like the resource owner, the end user (both human and virtual) to 1) issue tokens or 2) outsource this work it it wishes. In the latter case, the resource owner must at least understand what the token has rather than just pass the token.

Ideally, I would like this to be an OAuth work item: OAuth WG works very well, and it has gathered the best people to judge the task. I understand though that token specification is not presently in the charter, and therefore it can be discussed only in the context of changing the charter. And so I first wrote this in response to the item that you proposed, which I think is one step toward what I thought should be done.

Igor

---

From: William Mills <[email-masked]>
Date: Mon, 7 Feb 2011 20:40:54 -0800

I'm on the other side of this.  I think the opaque token is clean and allows for easy separation.  What more information do we need to provide to the client?  

I am not in favor of having a call back to the authenticating site as a requirement for OAuth in general, but if someone wants to define a token type to do that it's fine.  

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Kristoffer Gronowski
> Sent: Monday, February 07, 2011 6:26 PM
> To: [email-masked]
> Cc: [email-masked]
> As long as the authorization (AS) and the resource servers (RS) use the
> same identity source (or trusted federation of it).
> Except of the answer if the criteria was met I have been experimenting
> also in returning metadata from the AS so that a RS interceptor can be
> built.
> This would be a combination with the request input parameters. So you
> can start off with making sure that #1 is valid.
> Then if you have a more dynamic policy that is very endpoint specific
> it is far easier to implement it in code then in a general purpose
> policy server.
> 
> Then you can easily implement things like this protected resource needs
> scope X or Y Mon-Fri while Z on weekends.
> Another advantage is that the same code can work on your behalf in
> discovery mode to actually give you a clue what is needed at this very
> moment to access.
> And I am not saying that policy server would go away but for simple
> REST services this is a powerful framework where you do not have to
> mash all of you implementation into one big thing.
> 
> So that it why I was thinking that it might be a candidate for an
> optional interface that might be good to have.
> Indeed, anything that comes with the OAuth flow is an OAuth token.
> (From the security point of view, of course, that also means that
> anything that can be INSERTED into an OAuth flow will be an OAuth
> token...)  I am not criticizing  the  design decisions--I have  agreed
> with all of them.
> 
> Ideally, I would like this to be an OAuth work item: OAuth WG works
> very well, and it has gathered the best people to judge the task. I

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 08 Feb 2011 14:49:43 -0500

Definitely,  we have many common ideas!

I think we need to get an I-D out with a crisp proposal.

Igor

---

From: Eve Maler <[email-masked]>
Date: Fri, 11 Feb 2011 07:11:03 -0800

FWIW, the (OAuth-based) User-Managed Access group has done extensive work defining an interface between the AS (which we call an authorization manager for our use cases) and the resource server (which we call a host).  UMA's assumptions go straight to the hard case: The two entities are in completely different domains and might even start out without a trust relationship between them.

We've made a lot of progress in the last handful of months, e.g. defining how the host informs the AM what resource sets are being protected and what actions are possible on them (preparatory to allowing users to set access policy and allowing AMs to issue scoped tokens), and the SMART project's UMA/j implementation has been tracking our specs, but there's still more to do.  We're following JWT's development closely in order to take advantage of it for "meaningful" vs. opaque tokens when the time is right.

	Eve

>> other extension like the discovery, token revocation and other.

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl