Bill,
>> A WWW-Authenticate response header that identifies an authorization
>> server (AS) would be a great hypermedia-driven solution.
>> It tells the client app which AS a service trusts.
>> The client app can then get a token. ...
> Yeah, unfortunately the WWW-Authenticate solution advertisin
The problem is the password grant. Clients that support it would potentially
deliver the username and password without asking the user, or by prompting in
the UI itself and not through a web interaction with the AS.
>
> From: "Manger, James H"
>To: William Mi
Stephen, Hannes,
Given the intent to re-run LC, counsel need about 2-3 weeks to answer
the questions you've asked. Had the patent been disclosed in a timely
fashion they would have had that time long before LC. Having some
questions answered I believe will help LC discussion. I hope this
doesn'
I think there is a need for a signed token style OAuth 2 scheme, and MAC fills
this niche, although holder-of-key (as yet un-drafted) would also do this
nicely. Is MAC going to get picked up and driven to completion?
Do others feel this token style (and security properties) are needed? Or a
I also think it's worthwhile. OAuth2 doesn't provide a way to do a
signed-http-request in the way that OAuth1 does. I would definitely like
to see this draft make its way to completion, but I don't have the
crypto expertise to pick up editing it myself.
-- Justin
On 05/16/2012 11:51 AM, Will
3) I have read the IPR and I believe I could deploy this specification.
NOTE: I am not a legal expert, but I do have extensive experience with identity
related patents and after reviewing the claims, I do not believe that the OAuth
2.0 or OAuth bearer specifications infringe on patent 7272639.
for draft-hardjono-oauth-dynreg, would it make sense to have a type where
no redirect_url is passed and instead the client registration endpoint
assigns the redirect uri itself?
for instance, a mobile app might request this type of registration and the
client registration endpoint could assign the
> The problem is the password grant.
This doesn’t sound like a good reason to ditch AS discovery via an
WWW-Authenticate response header. Client apps using the password grant are only
a subset of OAuth clients, and a specialized subset at that. The spec
[draft-ietf-oauth-v2-26#section-4.3] says
The problem is not with the auth servers, it's with clients that support
password grant. If they trust info sent to them by a resource server they will
give up the goods.
>
> From: "Manger, James H"
>To: William Mills ; "oauth@ietf.org"
>Sent: Wednesday, Ma
