If the spec requires clients to implement both, the reality is most clients will only impliment one and be non compliant.
Given that openID Connect supports Bearer ONLY. Requiring clients to support MAC would cause clients to implement code that won't be used. It is up to the server to decide what formats it will support. If clients can't talk to the servers they need to then they will support the token format. I am opposed to making MAC MTI for Server or client. I don't want to start a token war, there are use cases for both, and perhaps others in the future. So I think that is a Canadian way of saying no change. John B. On 2011-11-02, at 5:11 PM, Eran Hammer-Lahav wrote: > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
