I might be interested too; agree that it's not core to this group.
Eve
On 23 Mar 2010, at 5:15 PM, Chuck Mortimore wrote:
Outside the scope of what this WG should be tackling in the core spec IMO,
but I’d be interested in working on a profile. There is a lot of this
use-case
Just getting a chance to review this – I apologize for not getting this before
the meeting started.
We’d like to see some form of an Assertion Profile, similar to section 5.2 from
draft-hardt-oauth-01. We have strong customer use-cases for an assertion
based flow, specifically SAML bearer
Hi David,
I have a couple of questions/comments:
§2 - The flows use shared secrets for client authentication only. What
about adding support for public-key-based signatures for that purpose as
an alternative? That's one of the use cases on
Separate from the Client trading a SAML assertion for an Access Token as
in this flow, we are interested in defining how a Client might use SAML
SSO messages to get an Access Token (comparable to OpenID/OAuth hybrid).
Anybody else interested?
paul
On 3/23/2010 1:47 PM, David Recordon wrote:
Missed it, included now!
http://github.com/daveman692/OAuth-2.0/commit/099c51025d33e9a9350468c3e57482785d9826e8
On Tue, Mar 23, 2010 at 12:09 PM, Chuck Mortimore
cmortim...@salesforce.com wrote:
By the way, did you see my little note at the end? It was kind of buried.
I think the oauth_mode
Outside the scope of what this WG should be tackling in the core spec IMO, but
I'd be interested in working on a profile. There is a lot of this use-case
being done in an ad-hoc manner on my platform.
-cmort
On 3/23/10 11:17 AM, Paul Madsen paul.mad...@gmail.com wrote:
Separate from the
On Tue, Mar 23, 2010 at 12:01 PM, David Recordon record...@gmail.com wrote:
§3
- Why is the parameter oauth_client_secret required for refreshing access
tokens? Use cases 2.2 and 2.3 do not require the client to use (possess) a
secret. Does this imply such client are not entitled to refresh
And I realize that this issue was created because WRAP describes a
different refresh token flow for each profile whereas this draft
combines them all together. I think it's important to realize that
implementors will want to write one refresh_token(identifier,
refresh_token, secret?) function and
On 2010-03-23, at 12:05 PM, Chuck Mortimore wrote:
No worries – I figured it would be easier to push for it’s inclusion if the
work were minimal.
We will definitely need to implement this style of profile, as will many
others, so it’s essential it ends in some spec. Personally I’d
David, great stuff -- thanks for putting this together! Here are a few
comments and questions from a quick read on the plane down to Anaheim, in spec
order (the weight/priority therefore varies widely).
Abstract
- delegate: The use of this word seems like it's different from how it's been
The goal of the, the authorization server advertises (such as via
documentation) the URIs of the following three endpoints wording was to allow
for a discovery process that is defined separately from this spec. Is that
unclear? Have other words to propose?
Eve, thanks for the detailed
On 21 Mar 2010, at 1:43 PM, David Recordon wrote:
The goal of the, the authorization server advertises (such as via
documentation) the URIs of the following three endpoints wording was to
allow for a discovery process that is defined separately from this spec. Is
that unclear? Have other
Selected thoughts in response:
On 21 Mar 2010, at 3:51 PM, David Recordon wrote:
Thanks! Comments inline and updated the repo
(http://github.com/daveman692/OAuth-2.0/commit/3193098ff45168dd0a65456334428b20215f848a).
On Sun, Mar 21, 2010 at 12:03 PM, Eve Maler e...@xmlgrrl.com wrote:
On Sun, Mar 21, 2010 at 8:26 PM, Eve Maler e...@xmlgrrl.com wrote:
Selected thoughts in response:
On 21 Mar 2010, at 3:51 PM, David Recordon wrote:
Thanks! Comments inline and updated the repo
(http://github.com/daveman692/OAuth-2.0/commit/3193098ff45168dd0a65456334428b20215f848a).
On
14 matches
Mail list logo
