Hi Justin, John, and Hannes
Is there an appetite to change the draft in such a way as:
- do not wrap access token itself. It could include at_hash though.
Rationale: Pop access token can be pretty large and I do not want to
double base64url encode.
- perhaps change ts to string to accommodat
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol of the IETF.
Title : OAuth 2.0 for Native Apps
Authors : William Denniss
John Bradley
Fil
Section 7.1.1 can probably be rolled up into Section 7.1, I agree it's a
bit out of place. I'll do that in -09.
+1 with the plan that this BCP documents the current state, and we can rev
it if and when that changes.
One comment to add: password eavesdropping isn't the only threat from
WebView, th
Hi Mike,
On 06/03/17 22:34, Mike Jones wrote:
> Thanks for the reply, Stephen. I'll try to find better
> interop-producing references where possible.
>
>
> In some cases, however, the values are intentionally intended to
> provide an identifier for a family of closely-related methods, such
> a
Thanks for the reply, Stephen. I'll try to find better interop-producing
references where possible.
In some cases, however, the values are intentionally intended to provide an
identifier for a family of closely-related methods, such as "otp", which covers
both time-based and HMAC-based OTPs.
Hi Mike,
Apologies - I updated the discuss ballot text [1] on Feb 28 but
must've not sent it as an email or something. Anyway...
[1] https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ballot/
On 06/03/17 20:38, Mike Jones wrote:
> Hi Stephen. The changes in draft -06 were intended
Hi Stephen. The changes in draft -06 were intended to address your DISCUSS
points. Are you satisfied with these changes or are there additional changes
you want? I'm asking partly because it's a week now until the submission
cutoff and if additional changes are needed, I'd like to make them t
You may want to note that RFC6749 itself recommends agains embedded for
security reasons:
An embedded user-agent poses a security challenge because resource
owners are authenticating in an unidentified window without access
to the visual protections found in most external user-agents.
On fido I can tell you that for security reasons U2F wont work from a web-view
currently.
Once we move to Web Auth (Fido 2) where the OS provides a API for apps to call
to get the token it will work but the tokens are audianced to the app based on
its developer key and bundle_id so that a app c
Hi William, Hi John,
I just re-read version -8 of the document again.
Two minor remarks only.
Editorial issue: Why do you need to introduce a single sub-section
within Section 7.1. (namely Section 7.1.1)?
Background question: You note that embedded user agents have the
disadvantage that the app
Hi William,
Thank you very much for your very detailed response!
May be I was a bit gruff. I simply expected best practices about Android
Account Manager vs. native OAuth in the Android Implementation Details section.
I did not realize, that it is addressed by “Non-Browser External User-Agents”
Here is the shepherd write-up:
https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-writeups/Writeup_OAuth_NativeApps.txt
Feedback appreciated. I will also do another shepherd review.
Ciao
Hannes
signature.asc
Description: OpenPGP digital signature
__
Hi Mike, Hi all,
as a shepherd I have reviewed the draft and I only have a few minor
comments.
RFC 2246 is included in the normative reference section but not
mentioned in the text.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, DOI 10.17487/RFC2246,
Yes, this matches my understanding of the discussions at the Seoul meeting.
On 03/04/2017 07:10 PM, Torsten Lodderstedt wrote:
> Hi Hannes,
>
> just for clarification: as far as I remember the proposal in Seoul was to
> turn the document into a BCP.
>
> Is this consistent with your expectation
14 matches
Mail list logo
