Hi Marius, I'm thinking the AS would create a 'dynamic' URI, embed it in
a QR code and add it to the response to the client (perhaps as you say
in addition to the raw URI & user code). There would be no user-code, as
we would no longer be constrained by the user's short-term memory for
strings
If (as you describe) the client creates the QR code from the 'raw' URI
and user-code that the AS provided it, then there would need be
sufficient OAuth smarts on the phone to reconstruct the URI and code
from the QR code the client displayed
If, on the other hand, the AS creates the QR code from a URI it
generates, then the phone need only launch a browser to load that URI.
paul
On 5/11/2010 4:55 PM, Marius Scurtescu wrote:
On Tue, May 11, 2010 at 4:12 AM, Paul Madsen<paul.mad...@gmail.com> wrote:
Yes that's the idea.
Where in the authorization server response would the QR code (or ref) go,
especially if it also includes the uri& user code?
I don't know how QR codes are generated, but I was assuming that the
device can generate one without any help from the authz server, only
based on uri and code. That's not going to work?
Marius
I don't see mention of an extensibility model by which additional params
could be defined/added
On 5/10/2010 2:03 PM, Marius Scurtescu wrote:
On Mon, May 10, 2010 at 6:20 AM, Paul Madsen<paul.mad...@gmail.com>
wrote:
Related, is anybody thinking of a variant of the device flow where the
user-agent sits on a device with QR-code capabilities, and so the user
needn't type anything (uri or code)?
The end user will point their phone to the device screen and the phone
browser will take it from there? I think the device still needs to
show the URI and code as fallback, in case the user does not have a
smart phone, right?
Does the spec need to change in any way to support this? Isn't this
just a particular implementation?
Marius
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
