Thomas Hardjono wrote:
(a) Oauth2.0 today is designed for low-assurance environments.
I don't think that was an objective. At least, the charter does not say
that...
So I think the WG is wasting a lot of time in trying to address whether the Client can keep secrets. The WG should just assume that the problem of keeping secrets is out of scope for Oauth. Unless we are trying to address high-assurance environments (and start talking about smartcards, HSMs, TPMs, trusted execution, trusted boot, etc), I think the WG should just move on.
Yes, but the objective here was to document *considerations*, which I
think the document has done very well. (By the way, personally I would
very much like to address high-assurance environments, but I respect the
consensus on getting 2.0 finished before this is addressed. All the
more, it is important to point out the potential weaknesses in the
security considerations section.)
ps. Section 4.1 is OK, but this WG will not be able to solve many of the
problems listed in Section 4.1
I have a different opinion on that, which is much more optimistic. But,
again, the objective of considerations is posing the problems, and this
is done very well, in my opinion.
(b) The current text of Section 9 says:
]]]] Native applications SHOULD use the authorization code
]]]] grant type flow without client password credentials (due to their
]]]] inability to keep the credentials confidential) to obtain
]]]] short-lived access tokens, and use refresh tokens to maintain access.
When it comes to "keeping secrets" I don't know why we are assuming that a
native application (software running in user-space managed by an OS) is any worse than a
browser (user-agent). Did I misunderstood the definition of a native application?
Maybe I misunderstood something, but I think that native applications
rely on OS for keeping secrets.
Igor
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
