On 11/03/2011 09:25 AM, Eran Hammer-Lahav wrote:
It can help by telling servers that as long as they support one of the MTI
types, they will be able to interop. Of course, they don't have to.
My feeling is that until there is an actual discovery experience out there that
works, this kind of interop is not really an issue ATM.
From what I can tell as a developer, it seems that every oauth server
deployment
comes with their very own oauth client library/sdk. So there's a twitter
one, a g+ one,
a fb one, etc. Ultimately there may be an oauth equivalent to openssl,
but it's
not there afaik, and probably won't be for a while since the library/sdk
needs to
support php, perl, python, ruby, blah, blah, blah instead of just a C
library with
higher level language specific veneers on top of it as needed.
So the reality is that any unified client is going to have to support
what servers
demand, not the other way around. Which means it's going to have to be a
kitchen sink
client library to handle the various choices that servers make. So I'd
say no to
any form of an sdp-like* offer/answer protocol; it's just easier to keep
adding to
the client kitchen sink.
Mike
[*] sdp offer/answer was necessary because of _hardware_ limitations...
usually because
of codec complexity where an endpoint physically might not be able to
interoperate.
that's good motivation. I doubt there's anything comparable with oauth.
EHL
-----Original Message-----
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Thursday, November 03, 2011 5:46 AM
To: William Mills
Cc: Eran Hammer-Lahav; John Bradley; Torsten Lodderstedt; oauth@ietf.org
Subject: Re: [OAUTH-WG] AD review of -22
This is exactly what I was thinking of. If a given token type is MTI for
clients,
but servers can do whatever they want (this, as I read it, is what was
suggested), how does the MTI bit help interop at all?
-- Justin
On Wed, 2011-11-02 at 15:48 -0700, William Mills wrote:
I actually think the protected resource specifies the token type(s) in
either it's service docs or discovery information, and it does know
knowing it's authentication server will issue compatible tokens. The
client may encounter endpoints requiring token types it doesn't
support, and it needs to fail gracefully. The client may select any
supported OAuth 2 scheme it understands which the PR supports.
I am not in favor of specifying MUST for any particular flavor of
token.
What is the value of mandating a token type?
-bill
__________________________________________________________
____________
From: Eran Hammer-Lahav<e...@hueniverse.com>
To: John Bradley<ve7...@ve7jtb.com>; Torsten Lodderstedt
<tors...@lodderstedt.net>
Cc: "oauth@ietf.org"<oauth@ietf.org>
Sent: Wednesday, November 2, 2011 1:11 PM
Subject: Re: [OAUTH-WG] AD review of -22
Do you want to see no change or adjust it to client must implement
both, server decides which to use.
EHL
__________________________________________________________
____________
From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of
John Bradley [ve7...@ve7jtb.com]
Sent: Wednesday, November 02, 2011 1:06 PM
To: Torsten Lodderstedt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] AD review of -22
+1
On 2011-11-02, at 4:45 PM, Torsten Lodderstedt wrote:
Hi Stephen,
I'm concerned about your proposal (7) to make support for MAC a MUST
for clients and BEARER a MAY only. In my opinion, this does not
reflect the group's consensus. Beside this, the security threat
analysis justifies usage of BEARER for nearly all use cases as long
as HTTPS (incl. server authentication) can be utilized.
regards,
Torsten.
Am 13.10.2011 19:13, schrieb Stephen Farrell:
Hi all,
Sorry for having been quite slow with this, but I had a bunch of
travel recently.
Anyway, my AD comments on -22 are attached. I think that the first
list has the ones that need some change before we push this out
for IETF LC, there might or might not be something to change as a
result of the 2nd list of questions and the rest are really nits
can be handled either now or later.
Thanks for all your work on this so far - its nearly there IMO and
we should be able to get the IETF LC started once these few things
are dealt with.
Cheers,
S.
_______________________________________________
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
_______________________________________________
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
