Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

[Mike Jones]

Hi Peter,

Fair enough.  I'll take an action item to read RFC 6365 and review the related 
text accordingly.

The main point of my commentary was that the processing of the parsed JSON 
would be the same no matter what the original encoding used was.

For what it's worth, I think that the two paragraphs quoted from the recent 
OpenID Connect Registration draft use the terminology correctly (but again, 
I'll read RFC 6365 in a bit and try to check for myself).  If they don't (since 
you're volunteering to read , brave man that you are :-) ), suggested 
corrections would be appreciated.  They're repeated below...

Thanks again,
-- Mike

Human-readable Client Metadata values and Client Metadata values that reference 
human-readable values MAY be represented in multiple languages and scripts. For 
example, values such as client_name, tos_uri, policy_uri, logo_uri, and 
client_uri might have multiple locale-specific values in some Client 
registrations.

…

If such a human-readable field is sent without a language tag, parties using it 
MUST NOT make any assumptions about the language, character set, or script of 
the string value, and the string value MUST be used as-is wherever it is 
presented in a user interface. To facilitate interoperability, it is 
RECOMMENDED that any human-readable fields sent without language tags contain 
values suitable for display on a wide variety of systems.

-Original Message-
From: Peter Saint-Andre [mailto:stpe...@stpeter.im] 
Sent: Monday, March 25, 2013 6:26 PM
To: Mike Jones
Cc: Justin Richer; Manger, James H; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable 
names

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 3/25/13 12:08 PM, Mike Jones wrote:
> FYI, the following version of this wording was incorporated into the 
> OpenID Connect Registration spec.  I also found the phrase 
> “internationalized UTF-8 string” ambiguous and so revised it.
> Also, UTF-8 is just plain wrong, as once you’re in JSON you’re just 
> dealing with Unicode strings, whether they were originally encoded in 
> UTF-8, UTF-16, or another encoding before parsing.

Mike and others, please read RFC 6365 at the very least to get some of the 
terminology right here. For example, a Unicode code point is simply a numbered 
point in a coded character set, say, U+03C0 (pi).
That code point is the same thing no matter whether it is written on a piece of 
paper, mentioned in spoken text, etc. In an electronic representation on the 
wire or in a file, the code point MUST be encoded using something like UTF-8 
(which we prefer in IETF protocols) or UTF-16 or whatever. So it is incorrect 
to say that "UTF-8 is just plain wrong, as once you’re in JSON you’re just 
dealing with Unicode strings". It doesn't work that way!

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRUPkaAAoJEOoGpJErxa2pJmUP/i4anZjL5pia4vJUA1RaY0Ht
ec6ItzKGZROEsIPM9jucFvrKyFYnvJARWYHQloWdnv89CCe0XzgX9Kr7LoLJuu+8
AHOosP6NWwxM2TR5PLC0akYKdyPnC6zenEyd94fx2Q12LXGmIBN6g3upveqmjsKW
EIk5VTQLV30tXIegmNbVZ6xbflw7rnXuRLc0HTTervAvQSTN9K4qVboDdFyiv3Si
oahzfxaEIOHo1ErljK2UzEc5YS7pQjwlPevzL2bc84ZJmuf9SwTD6vLUEeps0tAO
6dRb3B5gs2RFryLQGJ3/M0E4RL+aWc4zVd7tbFh5wF72uUA2o2BwEE6vyMdfuKmn
wgYtN9Tkxg9DlOQdfXg6FY5tk4mrWL/i1um1NXgTIy6b7loAZnD7yrliYWjtgBVf
Kns+QZOGgO2mkwnkLPI2KwRHRgX4JnXeDZYS1Kcg9yscq/Pdkb+8BfkNbn40TO8M
eEuq/mvvU3moAI3+TM6CbVJAwZqmVNsPiVv4M3tzA0lhgditq+rOHiQRvnoMwpzP
NLUBu0AJJUs3fnqf+YlG6jCS6lIT9gw/HMCjt1VVzm+hA+ntp5hqRBdXI0xqLyiN
LlYTI8W+BRPbnB9bhMX/KKgnvrKo/5zJZWmn1u/GztSapGP5cOr9w7DS/beYiC9K
5LgFphry8ahkTmR/BnD5
=UGRp
-END PGP SIGNATURE-
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 3/25/13 9:14 AM, Justin Richer wrote:
> No problem, it's important that we be very precise about this bit
> of text. There are many terms in this space with subtle differences
> between them, so I'm glad to have others with more experience
> reading over it.

RFC 6365 is your friend. :-)

And no, I have not read the entire thread on the topic here, but if
pressed into service I will review the proposed text. This i18n stuff
can be tricky. ;-)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRUPqwAAoJEOoGpJErxa2pqGEP/AsJ+6Tknwh/KinjSazu4J+W
ENn4S3g4xmslGIyePDSZMM9gu2+/HEVREsS+g3dN7luraQSnRgKGNJsykyk2oXPf
/SoOzL9m2Y4KfF6sMcMH4wBizfd5AiravqMcVJKgBfmmu3L/F4tjr5+b5IqdLZGq
8gST/SUCwtTGcK/Une8Hl5x+DBb0qgJz30gv3fbuC0R6XRwuPZuX+cvrCoUTYVB9
hJGF26QS7F08Kexc5liRRJqbmkb2Y5W0d5SY4d/+il2VyUkHbyg4FlNcruGrQsHk
F3r5LId57ghobD9RaXj16uQHMRgSgNgslIjYIFDobWgB55gYckNmMw6h3tX3VCih
UeRHLltd3s+zYCAf6pSBmcej8H3bR3TnCIuK7NqsqBfrQDDAFok9WECyjxHkc7xt
tPltZmBg/W+Xi4qEEkk+hf+HoeWh0/4XXnmiIh10gvuJJjbul60LeaCM1VLJo0Nj
WbMJfQv1kY4Dh+OpVzW+41WXYDPJOUVzXlR7EIDopob7JEhRvPnMVRFTAueCI2x7
6s56RVOXDRGXOygcX+3A+WuzqRX0HK7PYdEjOdnhNklBaCnbCCVTQPTGvzWsN/Dr
2dP2tz5sCTzzylbx+TwmMb8m5C9D1/DYN8e2la4eZQf3Vp+HQpMCvQEohWcYp/34
PnvAa39wUT+2hF0fnDxH
=4HvZ
-END PGP SIGNATURE-
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 3/25/13 9:11 AM, Justin Richer wrote:
> "Internationalization is the process of designing a software
> application so that it can be adapted to various languages and
> regions without engineering changes." (From 
> http://en.wikipedia.org/wiki/Internationalization_and_localization)
>
>  What this means in our case is that you'd want a string that would
> be usable on the widest variety of systems that you care about
> without them having to do something special to handle it. For some,
> that's going to mean ASCII. For others, it's going to mean some
> common local script.

Again, please read RFC 6365. ASCII means several things (is it a
character encoding scheme, a coded character set, etc.?), but in these
days of Unicode and UTF-8 it's least confusing to refer to it only as
the ASCII range of characters within the Unicode coded character set
since the characters in the ASCII range are represented using the same
bytes under UTF-8 as they were back in the old days of the ASCII
character encoding scheme.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRUPpFAAoJEOoGpJErxa2p+mgP/1XLmRz8HW7ki8YXNWZgKnb1
Nwt2DumjNMere7Q2kTr8fDjs3zmAxNM8HsNhO2tmTtTQ7Vxr9QtUftrLoM/TnXPA
zKmyyEl5CUDntjZHHg8c5ab7/rEkdwA4dAAkKBb3yaQr7OFRrQ7XnmVo94QcBBKh
8ieGNV4E5QS6EwIE2V+h7blEfM8VlG0Fk3DFTtfvmcCXf5LFexmuKrMhwf2kmPZe
cDiue+Vz75isM6YvVXjp15GSNEWPZS3zjwWuOu3nPbzkOXKgx2qmy3Kg1eE/V1jb
kWWkotu3HFXvKT7pm52nTkfjjDGhY7VbM9dt7m1FukOlOb7L5MgxxAWVxaSFmpOg
qctxdIcqwMBbbbJT+hTzB7/LBQtj8kXTiqe8AZLjAkJVEbZxkY5GBufG+MaX/M/y
bJo0bojqc33sN+jhnSxRRCkr5K7z31L+b80SNGSmOK/wERdepzQcufqBmicgfOds
ctdhFR3K/iXWMnMvBoDMTKSDVTVSUVX43b6ClYMQ/fGIoUl61StgIX7HuYDw3KDK
iq80u+UF7FK2Ea4qjsMQi9YhnOKBG7DLjB0s249Zlc4nGtBy2RSCqQIUs/KWkPBa
jFQiRLTMxbdLx0L0UYnncPr3ULsmkRbpkJF6C5CPdu4Skz6k16kgqcXdbzStBIZj
xqwa939rbFMTwIcWSZE+
=lJMh
-END PGP SIGNATURE-
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 3/25/13 12:08 PM, Mike Jones wrote:
> FYI, the following version of this wording was incorporated into
> the OpenID Connect Registration spec.  I also found the phrase 
> “internationalized UTF-8 string” ambiguous and so revised it.
> Also, UTF-8 is just plain wrong, as once you’re in JSON you’re just
> dealing with Unicode strings, whether they were originally encoded
> in UTF-8, UTF-16, or another encoding before parsing.

Mike and others, please read RFC 6365 at the very least to get some of
the terminology right here. For example, a Unicode code point is
simply a numbered point in a coded character set, say, U+03C0 (pi).
That code point is the same thing no matter whether it is written on a
piece of paper, mentioned in spoken text, etc. In an electronic
representation on the wire or in a file, the code point MUST be
encoded using something like UTF-8 (which we prefer in IETF protocols)
or UTF-16 or whatever. So it is incorrect to say that "UTF-8 is just
plain wrong, as once you’re in JSON you’re just dealing with Unicode
strings". It doesn't work that way!

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRUPkaAAoJEOoGpJErxa2pJmUP/i4anZjL5pia4vJUA1RaY0Ht
ec6ItzKGZROEsIPM9jucFvrKyFYnvJARWYHQloWdnv89CCe0XzgX9Kr7LoLJuu+8
AHOosP6NWwxM2TR5PLC0akYKdyPnC6zenEyd94fx2Q12LXGmIBN6g3upveqmjsKW
EIk5VTQLV30tXIegmNbVZ6xbflw7rnXuRLc0HTTervAvQSTN9K4qVboDdFyiv3Si
oahzfxaEIOHo1ErljK2UzEc5YS7pQjwlPevzL2bc84ZJmuf9SwTD6vLUEeps0tAO
6dRb3B5gs2RFryLQGJ3/M0E4RL+aWc4zVd7tbFh5wF72uUA2o2BwEE6vyMdfuKmn
wgYtN9Tkxg9DlOQdfXg6FY5tk4mrWL/i1um1NXgTIy6b7loAZnD7yrliYWjtgBVf
Kns+QZOGgO2mkwnkLPI2KwRHRgX4JnXeDZYS1Kcg9yscq/Pdkb+8BfkNbn40TO8M
eEuq/mvvU3moAI3+TM6CbVJAwZqmVNsPiVv4M3tzA0lhgditq+rOHiQRvnoMwpzP
NLUBu0AJJUs3fnqf+YlG6jCS6lIT9gw/HMCjt1VVzm+hA+ntp5hqRBdXI0xqLyiN
LlYTI8W+BRPbnB9bhMX/KKgnvrKo/5zJZWmn1u/GztSapGP5cOr9w7DS/beYiC9K
5LgFphry8ahkTmR/BnD5
=UGRp
-END PGP SIGNATURE-
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

[SM]

Hi Justin,
At 08:11 25-03-2013, Justin Richer wrote:
"Internationalization is the process of designing a software 
application so that it can be adapted to various languages and 
regions without engineering changes." (From


There is some discussion about internationalization in RFC 6365.

Regards,
-sm 


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

[Mike Jones]

FYI, the following version of this wording was incorporated into the OpenID 
Connect Registration spec.  I also found the phrase “internationalized UTF-8 
string” ambiguous and so revised it.  Also, UTF-8 is just plain wrong, as once 
you’re in JSON you’re just dealing with Unicode strings, whether they were 
originally encoded in UTF-8, UTF-16, or another encoding before parsing.

Human-readable Client Metadata values and Client Metadata values that reference 
human-readable values MAY be represented in multiple languages and scripts. For 
example, values such as client_name, tos_uri, policy_uri, logo_uri, and 
client_uri might have multiple locale-specific values in some Client 
registrations.

…

If such a human-readable field is sent without a language tag, parties using it 
MUST NOT make any assumptions about the language, character set, or script of 
the string value, and the string value MUST be used as-is wherever it is 
presented in a user interface. To facilitate interoperability, it is 
RECOMMENDED that any human-readable fields sent without language tags contain 
values suitable for display on a wide variety of systems.

Best wishes,
-- Mike

From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Justin Richer
Sent: Monday, March 25, 2013 8:12 AM
To: Manger, James H
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable 
names

"Internationalization is the process of designing a software application so 
that it can be adapted to various languages and regions without engineering 
changes." (From 
http://en.wikipedia.org/wiki/Internationalization_and_localization)

What this means in our case is that you'd want a string that would be usable on 
the widest variety of systems that you care about without them having to do 
something special to handle it. For some, that's going to mean ASCII. For 
others, it's going to mean some common local script.

And yes, the # character is appended to the field name, good catch.

 -- Justin

On 03/21/2013 09:43 PM, Manger, James H wrote:
What is an “internationalized UTF-8 string”?

P.S. It would be worth explicitly stating that the # character and RFC5646 
language tag are appended *to the field name* (not the value). I assume this is 
right.

--
James Manger

From: oauth-boun...@ietf.org 
[mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Friday, 22 March 2013 5:15 AM
To: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable 
names

We discussed this issue on the OpenID Connect WG call this morning, in a 
conversation that included myself, George Fletcher, Nat Sakimura, Mike Jones, 
and John Bradley (among others) as active participants in this thread. After 
lots of debate, we propose that the OAuth DynReg adopt the hashtag-based 
localization method of OIDC (and it seems, possibly webfinger) and explicitly 
declare that neither the client nor the server make any assumptions about the 
content of the string and treat it as just a string. I'm proposing this text to 
that effect (with the references to OIDC-messages removed and replaced with the 
rule description itself in OAuth DynReg):
Fields with human-readable values or references to human-readable values, such 
as client_name, tos_uri, policy_uri, and client_uri, MAY be represented in 
multiple languages and scripts, specified by appending a # character and the 
RFC5646 language tag. If any such human-readable field is sent without a 
language tag, the server and the client MUST NOT make any assumptions about the 
language, character set, or script of the value string, and the value string 
MUST be used as-is wherever it is presented in either the client or server UI. 
To facilitate interoperability, it is RECOMMENDED that any fields sent without 
language tags contain an internationalized UTF-8 string suitable for display on 
a wide variety of systems, and it is RECOMMENDED that clients send fields 
without language tags in addition to any more-specifically denominated values.

Plus some examples.

(Anyone whose name I took in vain, please feel free to correct me.)

 -- Justin

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth mobile flow

[Justin Richer]

This approach is what we've implemented in a few places, most notably on 
the hReader iOS app (code is in some branch or fork of 
https://github.com/projecthreader/hReader, I'm told it's going to be 
pulled into that main branch soon though). Here we pre-register the 
hReader app with a single redirect URI of hreader://oauth (or something 
along those lines) and use that as the callback. We also use the system 
browser as opposed to embedding a web form view, as there are several 
potential security and usability problems when using an embedded browser 
that range from loss of session management to the embedded browser 
leaking the credentials to the client app (which is exactly what OAuth 
is trying to avoid, after all).


 -- Justin



On 03/25/2013 07:51 AM, Brian Campbell wrote:
This little presentation from last year talks about OAuth & mobile. In 
a nutshell, it discusses using the authorization code grant and a 
redirect uri with a custom scheme.


http://www.slideshare.net/briandavidcampbell/is-that-a-token-in-your-phone-in-your-pocket-or-are-you-just-glad-to-see-me-oauth-20-and-mobile-devices


On Sun, Mar 24, 2013 at 1:47 PM, Security Developer 
> wrote:


Hi,

Can any body please help in describing the OAuth flow for mobile
applications?

Thanks for your time.

___
OAuth mailing list
OAuth@ietf.org 
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

[Justin Richer]

"Internationalization is the process of designing a software application 
so that it can be adapted to various languages and regions without 
engineering changes." (From 
http://en.wikipedia.org/wiki/Internationalization_and_localization)


What this means in our case is that you'd want a string that would be 
usable on the widest variety of systems that you care about without them 
having to do something special to handle it. For some, that's going to 
mean ASCII. For others, it's going to mean some common local script.


And yes, the # character is appended to the field name, good catch.

 -- Justin


On 03/21/2013 09:43 PM, Manger, James H wrote:


What is an “internationalized UTF-8 string”?

P.S. It would be worth explicitly stating that the # character and 
RFC5646 language tag are appended **to the field name** (not the 
value). I assume this is right.


--

James Manger

*From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On 
Behalf Of *Justin Richer

*Sent:* Friday, 22 March 2013 5:15 AM
*To:* oauth@ietf.org WG
*Subject:* Re: [OAUTH-WG] Registration: Internationalization of 
Human-Readable names


We discussed this issue on the OpenID Connect WG call this morning, in 
a conversation that included myself, George Fletcher, Nat Sakimura, 
Mike Jones, and John Bradley (among others) as active participants in 
this thread. After lots of debate, we propose that the OAuth DynReg 
adopt the hashtag-based localization method of OIDC (and it seems, 
possibly webfinger) and explicitly declare that neither the client nor 
the server make any assumptions about the content of the string and 
treat it as just a string. I'm proposing this text to that effect 
(with the references to OIDC-messages removed and replaced with the 
rule description itself in OAuth DynReg):


Fields with human-readable values or references to human-readable 
values, such as client_name, tos_uri, policy_uri, and client_uri, MAY 
be represented in multiple languages and scripts, specified by 
appending a # character and the RFC5646 language tag. If any such 
human-readable field is sent without a language tag, the server and 
the client MUST NOT make any assumptions about the language, character 
set, or script of the value string, and the value string MUST be used 
as-is wherever it is presented in either the client or server UI. To 
facilitate interoperability, it is RECOMMENDED that any fields sent 
without language tags contain an internationalized UTF-8 string 
suitable for display on a wide variety of systems, and it is 
RECOMMENDED that clients send fields without language tags in addition 
to any more-specifically denominated values.



Plus some examples.

(Anyone whose name I took in vain, please feel free to correct me.)

 -- Justin



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth mobile flow

[Shane B Weeden]

What I did in my OAuth 2.0 server environment was allow a client to
self-register without a redirect URI. If they do that, then use the azncode
flow, the azncode is displayed on the screen and the resource owner figures
out for themselves how to get it to the client. Quite similar in principal
to oob in OAuth 1.0 as you suggested.  And yes - you can even try that
pattern out for yourself on my demo OAuth server. Take a read of
https://www-304.ibm.com/connections/blogs/sweeden/entry/oauth_demonstration_environment
 for details on how to get yourself a client_id. I do some custom stuff for
mobileClient - like shrink the authorization code to six lowercase chars
and reduce it's lifetime to 60 seconds so it can be more easily typed into
a phone keyboard, but ultimately that's just config.

In my demos you saw two options for delivery - type it in, or scan it in
via QR. Obviously there are several security and operational considerations
to think about, but ultimately provided the resource owner does securely
deliver the code to the client it's fundamentally ok. You can get more
elaborate than that for mobile scenarios - for example you can use a web
view of the mobile application itself to interact with the resource owner
then send the azncode back via a push notification service. This has rouge
app / password phishing implications that I don't like and is no better
from a security perspective than doing resource owner password credentials
flow with a public client id, but again it's still a possibility.

Regards,
Shane.





From:   Sergey Beryozkin 
To: oauth@ietf.org
Date:   25/03/2013 06:01 PM
Subject:Re: [OAUTH-WG] OAuth mobile flow
Sent by:oauth-boun...@ietf.org



Hi Shane
On 25/03/13 00:54, Shane B Weeden wrote:
> There are several options. I've developed a few based on azn code flow
with
> custom "delivery" of the code, and also resource owner password
credentials
> flow with a public client id (although I personally don't like the idea
of
> ever presenting my real credentials to the phone but business owners seem
> to still want to do that).
>
> These might give you an idea:
>
https://www-304.ibm.com/connections/blogs/sweeden/entry/mobile_oauth_application_demonstration

>
https://www-304.ibm.com/connections/blogs/sweeden/entry/mobile_demonstration_under_the_hood

> http://www.youtube.com/watch?v=cLLrZMt_hII

This is interesting, thank you.
I'm just wondering, how does you application decide that the access
token is to be returned effectively out of band (which reminds me of the
'oob' redirect uri from OAuth 1.0).

Looks like the client_id being equal to "mobileClient" (in your demo) is
a hint.

If yes, then would you (and others) see any benefit in actually
attempting to get an 'oob' redirect_uri value standardized ? (sorry if
this was already raised earlier).

I can see how I can get a generic framework for supporting writing
OAuth2 applications returning the code directly to the browser even
without having 'oob' redirect uri - example, one can configure the
authorization endpoint to recognize that a particular client_id requires
an out of band delivery of the access token, etc.

FYI, I like the device code flow you linked to though appreciate the
simplicity of returning the token to the browser in demos, etc...

Cheers, Sergey

>
> Regards,
> Shane.
>
>
>
> From:  Security Developer
> To:OAuth@ietf.org
> Date:  25/03/2013 05:52 AM
> Subject:   [OAUTH-WG] OAuth mobile flow
> Sent by:   oauth-boun...@ietf.org
>
>
>
> Hi,
>
> Can any body please help in describing the OAuth flow for mobile
> applications?
>
> Thanks for your time.___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth mobile flow

[Brian Campbell]

This little presentation from last year talks about OAuth & mobile. In a
nutshell, it discusses using the authorization code grant and a redirect
uri with a custom scheme.

http://www.slideshare.net/briandavidcampbell/is-that-a-token-in-your-phone-in-your-pocket-or-are-you-just-glad-to-see-me-oauth-20-and-mobile-devices


On Sun, Mar 24, 2013 at 1:47 PM, Security Developer <
security.develope...@gmail.com> wrote:

> Hi,
>
> Can any body please help in describing the OAuth flow for mobile
> applications?
>
> Thanks for your time.
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth mobile flow

[Sergey Beryozkin]

Hi Shane
On 25/03/13 00:54, Shane B Weeden wrote:

There are several options. I've developed a few based on azn code flow with
custom "delivery" of the code, and also resource owner password credentials
flow with a public client id (although I personally don't like the idea of
ever presenting my real credentials to the phone but business owners seem
to still want to do that).

These might give you an idea:
https://www-304.ibm.com/connections/blogs/sweeden/entry/mobile_oauth_application_demonstration
https://www-304.ibm.com/connections/blogs/sweeden/entry/mobile_demonstration_under_the_hood
http://www.youtube.com/watch?v=cLLrZMt_hII


This is interesting, thank you.
I'm just wondering, how does you application decide that the access 
token is to be returned effectively out of band (which reminds me of the 
'oob' redirect uri from OAuth 1.0).


Looks like the client_id being equal to "mobileClient" (in your demo) is 
a hint.


If yes, then would you (and others) see any benefit in actually 
attempting to get an 'oob' redirect_uri value standardized ? (sorry if 
this was already raised earlier).


I can see how I can get a generic framework for supporting writing 
OAuth2 applications returning the code directly to the browser even 
without having 'oob' redirect uri - example, one can configure the 
authorization endpoint to recognize that a particular client_id requires 
an out of band delivery of the access token, etc.


FYI, I like the device code flow you linked to though appreciate the 
simplicity of returning the token to the browser in demos, etc...


Cheers, Sergey



Regards,
Shane.



From:   Security Developer
To: OAuth@ietf.org
Date:   25/03/2013 05:52 AM
Subject:[OAUTH-WG] OAuth mobile flow
Sent by:oauth-boun...@ietf.org



Hi,

Can any body please help in describing the OAuth flow for mobile
applications?

Thanks for your time.___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth