[OAUTH-WG] Question on section 10.3 in Core spec.
Hi all, I'm now translating OAuth 2.0 Core & Bearer specs into Japanese with my friends. I have one question on section 10.3 in Core spec. "To prevent this form of attack, native applications SHOULD use external browsers instead of embedding browsers in an iframe when requesting end-user authorization." Here, what do you mean for "in an iframe"? I thought it means "embedded browser is in an iframe", but I can't imagine it can be.. Thanks in advance -- nov matake ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Question on section 10.3 in Core spec.
Hi, you are right, iframe is not the correct techniquehere. Browsers are embedded into a native UI using browser widget or something similar. I think "... embedding a browser into the application's user interface when requesting end-user authorization ..." would fit better. regards, Torsten. Am 11.11.2011 09:23, schrieb matake@gmail: Hi all, I'm now translating OAuth 2.0 Core& Bearer specs into Japanese with my friends. I have one question on section 10.3 in Core spec. "To prevent this form of attack, native applications SHOULD use external browsers instead of embedding browsers in an iframe when requesting end-user authorization." Here, what do you mean for "in an iframe"? I thought it means "embedded browser is in an iframe", but I can't imagine it can be.. Thanks in advance -- nov matake ___ 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] Question on section 10.3 in Core spec.
Ah, now I got it. Thanks! On 2011/11/11, at 22:59, Torsten Lodderstedt wrote: > Hi, > > you are right, iframe is not the correct techniquehere. Browsers are embedded > into a native UI using browser widget or something similar. I think "... > embedding a browser into the application's user interface when requesting > end-user authorization ..." would fit better. > > regards, > Torsten. > > Am 11.11.2011 09:23, schrieb matake@gmail: >> Hi all, >> >> I'm now translating OAuth 2.0 Core& Bearer specs into Japanese with my >> friends. >> I have one question on section 10.3 in Core spec. >> >> "To prevent this form of attack, native applications SHOULD use external >> browsers instead of embedding browsers in an iframe when requesting end-user >> authorization." >> >> Here, what do you mean for "in an iframe"? >> I thought it means "embedded browser is in an iframe", but I can't imagine >> it can be.. >> >> Thanks in advance >> >> -- >> nov matake >> ___ >> 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] Question on section 10.3 in Core spec.
You are asking about 10.13 I think. The important idea is to give the user a browser that gives them a browser bar so they can tell if the SSL and domain are correct. Some native applications (JS) may be able to invoke a frameless iframe browse window. It would be deter to be clear and translate as Full Frame external Browser window. No iframe only applies to some environments. At least that is how I read the section. John B. On 2011-11-11, at 3:23 AM, matake@gmail wrote: > Hi all, > > I'm now translating OAuth 2.0 Core & Bearer specs into Japanese with my > friends. > I have one question on section 10.3 in Core spec. > > "To prevent this form of attack, native applications SHOULD use external > browsers instead of embedding browsers in an iframe when requesting end-user > authorization." > > Here, what do you mean for "in an iframe"? > I thought it means "embedded browser is in an iframe", but I can't imagine it > can be.. > > Thanks in advance > > -- > nov matake > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Question on section 10.3 in Core spec.
Ah, right, 10.13 I meant. So I read the section as - "in an iframe" and "external browsers" are not related - and it's talking about "no address bar" situation. On 2011/11/13, at 0:13, John Bradley wrote: > You are asking about 10.13 I think. > > The important idea is to give the user a browser that gives them a browser > bar so they can tell if the SSL and domain are correct. > > Some native applications (JS) may be able to invoke a frameless iframe browse > window. > > It would be deter to be clear and translate as Full Frame external Browser > window. > > No iframe only applies to some environments. > > At least that is how I read the section. > > John B. > On 2011-11-11, at 3:23 AM, matake@gmail wrote: > >> Hi all, >> >> I'm now translating OAuth 2.0 Core & Bearer specs into Japanese with my >> friends. >> I have one question on section 10.3 in Core spec. >> >> "To prevent this form of attack, native applications SHOULD use external >> browsers instead of embedding browsers in an iframe when requesting end-user >> authorization." >> >> Here, what do you mean for "in an iframe"? >> I thought it means "embedded browser is in an iframe", but I can't imagine >> it can be.. >> >> Thanks in advance >> >> -- >> nov matake >> ___ >> 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] Question on section 10.3 in Core spec.
It is about the user trusting the browse the client is presenting. If the client is presenting a Authorization endpoint dialog in a embeded browser it controls or in a iframe there is more it can do to get the users login credentials or authorization from a site that the user docent know there are granting. Now a bad client is not going to follow this advice, because they are bad. This can only be effective if good clients follow the example and train users to notice when something suspicious is going on. John B. On 2011-11-12, at 8:04 PM, matake@gmail wrote: > Ah, right, 10.13 I meant. > > So I read the section as > - "in an iframe" and "external browsers" are not related > - and it's talking about "no address bar" situation. > > On 2011/11/13, at 0:13, John Bradley wrote: > >> You are asking about 10.13 I think. >> >> The important idea is to give the user a browser that gives them a browser >> bar so they can tell if the SSL and domain are correct. >> >> Some native applications (JS) may be able to invoke a frameless iframe >> browse window. >> >> It would be deter to be clear and translate as Full Frame external Browser >> window. >> >> No iframe only applies to some environments. >> >> At least that is how I read the section. >> >> John B. >> On 2011-11-11, at 3:23 AM, matake@gmail wrote: >> >>> Hi all, >>> >>> I'm now translating OAuth 2.0 Core & Bearer specs into Japanese with my >>> friends. >>> I have one question on section 10.3 in Core spec. >>> >>> "To prevent this form of attack, native applications SHOULD use external >>> browsers instead of embedding browsers in an iframe when requesting >>> end-user authorization." >>> >>> Here, what do you mean for "in an iframe"? >>> I thought it means "embedded browser is in an iframe", but I can't imagine >>> it can be.. >>> >>> Thanks in advance >>> >>> -- >>> nov matake >>> ___ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> > smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
