Proposed OAuth WRAP Offline Profile

[Evan Gilbert]

Following up on a previous discussion thread - here's a proposed profile to support getting an access token for a user by sending a wrap_client_id and wrap_client_secret.

Use Case: This profile is suitable where authorization might not be granted by the User directly, and the Client may need to access protected resources on behalf of User without ever having interacted with User.

The proposal is the simplest possible way to solve the use case, but make be less secure than some alternatives: The downsides of the proposal:

1. Makes the wrap_client_secret more powerful, and
2. Sends the wrap_client_secret over the wire more frequently.

Two alternatives that can be considered:

• Getting a Admin Access Token with your wrap_client_secret, then swapping the Admin Access Token for user-scoped access tokens. The ATT (AAT?) has less access to data than the wrap_client_secret and can be expired regularly.
• Signing requests with wrap_client_secret instead of sending the secret directly. This could be a form of SWT that is passed as an assertion for the assertion profile.

Evan

[Dick Hardt]

Hi Evan

Thanks for writing this up.

It looks the same to me as 5.1 except for the addition of the wrap_username parameter. Is that correct? 

Given that, it would seem that this could be an "extension" of 5.1, that could also include standardizing the value of wrap_scope. Thoughts?

Would it be an important feature in the use case(s) you are envisioning that usefulapp.com NOT preregister with company.com? Would you envision the admin generating a client  id and secret and entering them into usefulapp.com? I'm unclear on how you are thinking about provisioning.

-- Dick

btw: wrap_name and wrap_password were chosen in 5.1 instead of wrap_client_id and wrap_client_secret to clearly indicate the difference between autonomous profiles and user delegation profiles.

--

You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
To post to this group, send email to oauth-...@googlegroups.com.
To unsubscribe from this group, send email to oauth-wrap-w...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.
<OAuth WRAP Offline Profile.pdf>

[Evan Gilbert]

On Thu, Dec 31, 2009 at 12:17 PM, Dick Hardt <Dick....@microsoft.com> wrote:

Hi Evan

Thanks for writing this up.

It looks the same to me as 5.1 except for the addition of the wrap_username parameter. Is that correct? 

Given that, it would seem that this could be an "extension" of 5.1, that could also include standardizing the value of wrap_scope. Thoughts?

That makes sense to me - the wrap_name/wrap_password threw me for a bit of a loop and I wasn't sure whether it would make sense to extend. I'll write up a variation extending 5.1.

Would it be an important feature in the use case(s) you are envisioning that usefulapp.com NOT preregister with company.com? Would you envision the admin generating a client  id and secret and entering them into usefulapp.com? I'm unclear on how you are thinking about provisioning.

Preregistration would be required - the flow would be as you said. usefulapp.com would preregister at company.com and get a client id/ secret from company.com.

Note: this is a little simplified - the full use case is usefulapp.com preregistering at serviceprovider.com who provides protected resources for company.com. I don't think that changes anything in this flow, but wanted to mention.

 

-- Dick

btw: wrap_name and wrap_password were chosen in 5.1 instead of wrap_client_id and wrap_client_secret to clearly indicate the difference between autonomous profiles and user delegation profiles.

wrap_name/wrap_password was a big confusing to me - I thought it was a user name and user password when I first read the section. Also, this proposed extension would further blur the difference between 5.1 and the other profiles.

Would it make sense to switch to wrap_client_id & wrap_client_secret for 5.1?

[Dick Hardt]

On 2010-01-04, at 9:00 AM, Evan Gilbert wrote:

On Thu, Dec 31, 2009 at 12:17 PM, Dick Hardt <Dick....@microsoft.com> wrote:

<snip>

btw: wrap_name and wrap_password were chosen in 5.1 instead of wrap_client_id and wrap_client_secret to clearly indicate the difference between autonomous profiles and user delegation profiles.

wrap_name/wrap_password was a big confusing to me - I thought it was a user name and user password when I first read the section. Also, this proposed extension would further blur the difference between 5.1 and the other profiles.

Would it make sense to switch to wrap_client_id & wrap_client_secret for 5.1?

Brian and/or Allen had a good argument (IMHO) for why we purposely chose to use different names. 

Brian / Allen?

-- Dick