Mike Jones: Working Group Draft for OAuth 2.0 Act-As and On-Behalf-Of
Thought you would be interested in the following link, from the blog of Mike Jones of Microsoft. Topic: There's now an OAuth working group draft of the OAuth 2.0 Token Exchange specification, which provides Act-As and On-Behalf-Of functionality for OAuth 2.0. This functionality is deliberately modelled on the same functionality present in WS-Trust. Link: http://self-issued.info/?p=1276 Alan
Hi Alan, On 25/08/14 07:13, Sill, Alan wrote:
Thought you would be interested in the following link, from the blog of Mike Jones of Microsoft.
Topic: There's now an OAuth working group draft of the OAuth 2.0 Token Exchange specification, which provides Act-As and On-Behalf-Of functionality for OAuth 2.0. This functionality is deliberately modelled on the same functionality present in WS-Trust.
Interesting, although (to me) a little odd: OAuth is already about delegation, so providing a delegation framework within a delegation framework seems redundant. Another odd point is that the RP needs to know (a priori) the identity it wishes which, in general, it doesn't (c.f. OpenID Connect). So, the use-case seems to be RP needs a credential (X.509, Kerberos, ...) to communicate with some server that doesn't support OAuth but trusts the server issuing the credential --- perhaps for legacy services or ones that don't provide a web front-end? Anyhow, thanks for the pointer. Cheers, Paul.
Thanks, Paul. It was just for information. Separately but along similar lines, there is a document in the pipeline for more than a year now that Jim basney wrote and submitted for comments from this group that could use some action: ttp://redmine.ogf.org/dmsf_files/13113 - Word version http://goo.gl/VnMKXS - public Google Doc version http://goo.gl/T6VOty - editable Google Doc (contact Jim for edit access) You were the only person to reply back then - http://www.ogf.org/pipermail/idel-wg/2013-September/000012.html - but I have seen no activity on this since then, and Jim brought this up at the BoF on Identity Management Technologies that we held during the OGF 41 sessions at XSEDE 2014 in July. Can we get a little more activity on reading, reviewing and discussing the various use cases and Jim’s draft? Separately even from this, you may have noticed that OGF Redmine supports old-style OpenID logins via a variety of social media, and we would like to develop some more sophisticated capabilities soon too, or example the ability ti integrate or at least synchronize our repositories with GitHub via OpenID Connect, for example. So we are more than just interested bystanders and working group hosts on this issue. In any case, please do read the able links and be prepared to participate in or forward your thoughts for discussion on the email lists and/or at OGF 43 in London. Thanks, Alan On Aug 25, 2014, at 8:49 AM, Paul Millar <paul.millar@desy.de> wrote:
Hi Alan,
On 25/08/14 07:13, Sill, Alan wrote:
Thought you would be interested in the following link, from the blog of Mike Jones of Microsoft.
Topic: There's now an OAuth working group draft of the OAuth 2.0 Token Exchange specification, which provides Act-As and On-Behalf-Of functionality for OAuth 2.0. This functionality is deliberately modelled on the same functionality present in WS-Trust.
Interesting, although (to me) a little odd: OAuth is already about delegation, so providing a delegation framework within a delegation framework seems redundant.
Another odd point is that the RP needs to know (a priori) the identity it wishes which, in general, it doesn't (c.f. OpenID Connect).
So, the use-case seems to be RP needs a credential (X.509, Kerberos, ...) to communicate with some server that doesn't support OAuth but trusts the server issuing the credential --- perhaps for legacy services or ones that don't provide a web front-end?
Anyhow, thanks for the pointer.
Cheers,
Paul. _______________________________________________ Idel-wg mailing list Idel-wg@ogf.org https://www.ogf.org/mailman/listinfo/idel-wg
Yes, if we can get the activity (re)started by OGF42, that'd be great. As I remember WS-Trust, the advantage was you could build stuff like WS-Federation and support for SOAP, so a different use case from OAuth2. Also, OAuth does have some, er, features which can be troublesome in certain environments. See you in London, I hope. Cheers --jens ________________________________________ From: Sill, Alan [alan.sill@ttu.edu] Sent: 25 August 2014 18:47 To: Paul Millar Cc: idel-wg@ogf.org; Sill, Alan Subject: Re: [Idel-wg] Mike Jones: Working Group Draft for OAuth 2.0 Act-As and On-Behalf-Of Thanks, Paul. It was just for information. Separately but along similar lines, there is a document in the pipeline for more than a year now that Jim basney wrote and submitted for comments from this group that could use some action: ttp://redmine.ogf.org/dmsf_files/13113 - Word version http://goo.gl/VnMKXS - public Google Doc version http://goo.gl/T6VOty - editable Google Doc (contact Jim for edit access) You were the only person to reply back then - http://www.ogf.org/pipermail/idel-wg/2013-September/000012.html - but I have seen no activity on this since then, and Jim brought this up at the BoF on Identity Management Technologies that we held during the OGF 41 sessions at XSEDE 2014 in July. Can we get a little more activity on reading, reviewing and discussing the various use cases and Jim’s draft? Separately even from this, you may have noticed that OGF Redmine supports old-style OpenID logins via a variety of social media, and we would like to develop some more sophisticated capabilities soon too, or example the ability ti integrate or at least synchronize our repositories with GitHub via OpenID Connect, for example. So we are more than just interested bystanders and working group hosts on this issue. In any case, please do read the able links and be prepared to participate in or forward your thoughts for discussion on the email lists and/or at OGF 43 in London. Thanks, Alan On Aug 25, 2014, at 8:49 AM, Paul Millar <paul.millar@desy.de> wrote:
Hi Alan,
On 25/08/14 07:13, Sill, Alan wrote:
Thought you would be interested in the following link, from the blog of Mike Jones of Microsoft.
Topic: There's now an OAuth working group draft of the OAuth 2.0 Token Exchange specification, which provides Act-As and On-Behalf-Of functionality for OAuth 2.0. This functionality is deliberately modelled on the same functionality present in WS-Trust.
Interesting, although (to me) a little odd: OAuth is already about delegation, so providing a delegation framework within a delegation framework seems redundant.
Another odd point is that the RP needs to know (a priori) the identity it wishes which, in general, it doesn't (c.f. OpenID Connect).
So, the use-case seems to be RP needs a credential (X.509, Kerberos, ...) to communicate with some server that doesn't support OAuth but trusts the server issuing the credential --- perhaps for legacy services or ones that don't provide a web front-end?
Anyhow, thanks for the pointer.
Cheers,
Paul. _______________________________________________ Idel-wg mailing list Idel-wg@ogf.org https://www.ogf.org/mailman/listinfo/idel-wg
_______________________________________________ Idel-wg mailing list Idel-wg@ogf.org https://www.ogf.org/mailman/listinfo/idel-wg -- Scanned by iCritical.
Hi Paul, others, On Mon, Aug 25, 2014 at 03:49:56PM +0200, Paul Millar wrote:
Hi Alan,
On 25/08/14 07:13, Sill, Alan wrote:
Thought you would be interested in the following link, from the blog of Mike Jones of Microsoft.
Topic: There's now an OAuth working group draft of the OAuth 2.0 Token Exchange specification, which provides Act-As and On-Behalf-Of functionality for OAuth 2.0. This functionality is deliberately modelled on the same functionality present in WS-Trust.
Interesting, although (to me) a little odd: OAuth is already about delegation, so providing a delegation framework within a delegation framework seems redundant.
Another odd point is that the RP needs to know (a priori) the identity it wishes which, in general, it doesn't (c.f. OpenID Connect).
Maybe I'm wrong, but I would think that an interesting use-case is multi-step delegation. For single-step delegation standard OAuth2.0 is fine. But how should a resource server then do a further delegation step, so RP-1 want to request access to RP-2 on behalf of user. It could try to (mis)use the original token, but it's much better to require a new token. That means it must request a token on behalf of the original user. In that case, it also would know which identity to use, right? Or do I misunderstand your second remark? Cheers, Mischa
So, the use-case seems to be RP needs a credential (X.509, Kerberos, ...) to communicate with some server that doesn't support OAuth but trusts the server issuing the credential --- perhaps for legacy services or ones that don't provide a web front-end?
Anyhow, thanks for the pointer.
Cheers,
Paul. _______________________________________________ Idel-wg mailing list Idel-wg@ogf.org https://www.ogf.org/mailman/listinfo/idel-wg
-- Nikhef Room H155 Science Park 105 Tel. +31-20-592 5102 1098 XG Amsterdam Fax +31-20-592 5155 The Netherlands Email msalle@nikhef.nl __ .. ... _._. .... ._ ... ._ ._.. ._.. .._..
Hi Mischa, That sounds to me like a great use case. If you look at the life of a GSI proxy in the wild, you can see how many times it was delegated (like tree rings or something), and that alone suggests a need for multistep delegation. Cheers --jens On 16/09/2014 14:21, Mischa Salle wrote:
Hi Paul, others,
On Mon, Aug 25, 2014 at 03:49:56PM +0200, Paul Millar wrote:
Hi Alan,
Thought you would be interested in the following link, from the blog of Mike Jones of Microsoft.
Topic: There's now an OAuth working group draft of the OAuth 2.0 Token Exchange specification, which provides Act-As and On-Behalf-Of functionality for OAuth 2.0. This functionality is deliberately modelled on the same functionality present in WS-Trust. Interesting, although (to me) a little odd: OAuth is already about delegation, so providing a delegation framework within a delegation
On 25/08/14 07:13, Sill, Alan wrote: framework seems redundant.
Another odd point is that the RP needs to know (a priori) the identity it wishes which, in general, it doesn't (c.f. OpenID Connect).
Maybe I'm wrong, but I would think that an interesting use-case is multi-step delegation. For single-step delegation standard OAuth2.0 is fine. But how should a resource server then do a further delegation step, so RP-1 want to request access to RP-2 on behalf of user. It could try to (mis)use the original token, but it's much better to require a new token. That means it must request a token on behalf of the original user. In that case, it also would know which identity to use, right? Or do I misunderstand your second remark?
Cheers, Mischa
So, the use-case seems to be RP needs a credential (X.509, Kerberos, ...) to communicate with some server that doesn't support OAuth but trusts the server issuing the credential --- perhaps for legacy services or ones that don't provide a web front-end?
Anyhow, thanks for the pointer.
Cheers,
Paul. _______________________________________________ Idel-wg mailing list Idel-wg@ogf.org https://www.ogf.org/mailman/listinfo/idel-wg
_______________________________________________ Idel-wg mailing list Idel-wg@ogf.org https://www.ogf.org/mailman/listinfo/idel-wg
-- Scanned by iCritical.
On Thu, Sep 18, 2014 at 03:43:45PM +0100, Jensen, Jens (STFC,RAL,SC) wrote:
Hi Mischa,
That sounds to me like a great use case. If you look at the life of a GSI proxy in the wild, you can see how many times it was delegated (like tree rings or something), and that alone suggests a need for multistep delegation.
Hi Jens, just some background information: the use-case came up in the context of the CLARIN project: user contacts portal, portal contacts SP1, and SP1 must be able to contact SP2 on behalf of the original user. Apart from the last step, you can do this with standard OAuth2. However, by default AFAIK, the token is not really restricted, so nothing prevents SP1 from just using the token it got presented by the portal to contact SP2. You would want to constrain the scope to a specific service, such that any other service using that token will not be allowed access. Instead, the token could allow the first service to obtain a new token, which it could use to do the second step. Kerberos has something like that I belief, although I couldn't find the right reference. This is something you actually also would like to do with proxy certificates and for some reason has never been developed (see also RFC3820 3.8.2, 5.3.2, 5.4). Even though making such constrained delegation information private is hard (at least for proxies), it still would be a big improvement in security. Proxy theft would become a lot less interesting. Cheers, Mischa
On 16/09/2014 14:21, Mischa Salle wrote:
Hi Paul, others,
On Mon, Aug 25, 2014 at 03:49:56PM +0200, Paul Millar wrote:
Hi Alan,
Thought you would be interested in the following link, from the blog of Mike Jones of Microsoft.
Topic: There's now an OAuth working group draft of the OAuth 2.0 Token Exchange specification, which provides Act-As and On-Behalf-Of functionality for OAuth 2.0. This functionality is deliberately modelled on the same functionality present in WS-Trust. Interesting, although (to me) a little odd: OAuth is already about delegation, so providing a delegation framework within a delegation
On 25/08/14 07:13, Sill, Alan wrote: framework seems redundant.
Another odd point is that the RP needs to know (a priori) the identity it wishes which, in general, it doesn't (c.f. OpenID Connect).
Maybe I'm wrong, but I would think that an interesting use-case is multi-step delegation. For single-step delegation standard OAuth2.0 is fine. But how should a resource server then do a further delegation step, so RP-1 want to request access to RP-2 on behalf of user. It could try to (mis)use the original token, but it's much better to require a new token. That means it must request a token on behalf of the original user. In that case, it also would know which identity to use, right? Or do I misunderstand your second remark?
Cheers, Mischa
So, the use-case seems to be RP needs a credential (X.509, Kerberos, ...) to communicate with some server that doesn't support OAuth but trusts the server issuing the credential --- perhaps for legacy services or ones that don't provide a web front-end?
Anyhow, thanks for the pointer.
Cheers,
Paul. _______________________________________________ Idel-wg mailing list Idel-wg@ogf.org https://www.ogf.org/mailman/listinfo/idel-wg
_______________________________________________ Idel-wg mailing list Idel-wg@ogf.org https://www.ogf.org/mailman/listinfo/idel-wg
-- Scanned by iCritical.
_______________________________________________ Idel-wg mailing list Idel-wg@ogf.org https://www.ogf.org/mailman/listinfo/idel-wg
-- Nikhef Room H155 Science Park 105 Tel. +31-20-592 5102 1098 XG Amsterdam Fax +31-20-592 5155 The Netherlands Email msalle@nikhef.nl __ .. ... _._. .... ._ ... ._ ._.. ._.. .._..
participants (5)
-
jens.jensen＠stfc.ac.uk -
Jensen, Jens (STFC,RAL,SC)
-
Mischa Salle -
Paul Millar -
Sill, Alan