Discovery in general for OAuth isn't well understood. This conversation and others like it around the 'discovery' draft demonstrate that. But publishing AS metadata is something that is understood and already in wide use for Connect. The rough consensus (except for a very few but vocal dissenters) on this list over the last few weeks/months has been that draft-ietf-oauth-discovery should describing AS metadata and its location. It's been suggested that the title reflect that scope and I might even suggest that the document identifier be changed to avoid further confusion.
The IDP mixup is addressed by the AS identifying itself to the client in the authorization response (it has a few other things in it that arguably shouldn't be in or should be elsewhere but that's a different question). The Mix-Up Mitigation draft uses the issuer value to do that. Issuer becomes a logical name/identifier for an AS. And that can tie it to AS metadata or even discovery if/when that exists. But discovery or AS metadata isn't necessary there. Yes Tony, we'd all like to see a comprehensive solution but conflating different and unrelated things is only making matters worse (as I'm sure you are well aware). A 'bad RS' phishing for legitimate access tokens is a different kind of endpoint confusion. Most deployments now have a static relationship defined between RS and AS so it's more of a potential problem in the future. Despite the concern voiced about it the potential (as far as I can tell anyway), draft-hunt-oauth-bound-config provides a very nice attack vector for such a 'bad RS' by pointing to an AS to obtain tokens it could misuse at legitimate RS(s). John has alluded to this. There have been a number of incremental updates/extensions to OAuth 2.0 and there look to be more coming. Concerns have been expressed over the number of documents and implements knowing what to use when. I don't think the answer is to try and jam unrelated new stuff into new docs to keep the number of docs low is a good idea though. I'd much prefer to have concise and cohesive documents. The larger issue of confusion around too many documents should be addressed at a higher level. For example, something like an implementation guide or even something like an OAuth 2.1 that describes the available extensions and when/why one would use them. On Mon, Mar 14, 2016 at 4:29 PM, Anthony Nadalin <tony...@microsoft.com> wrote: > I would really like to see a comprehensive solution not this piece work, > so we know what we are solving and what we are not. > > -----Original Message----- > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hans Zandbelt > Sent: Monday, March 14, 2016 3:26 PM > To: Phil Hunt (IDM) <phil.h...@oracle.com>; John Bradley < > ve7...@ve7jtb.com> > Cc: oauth <oauth@ietf.org> > Subject: Re: [OAUTH-WG] New Version Notification for > draft-hunt-oauth-bound-config-00.txt > > On 3/14/16 10:17 PM, Phil Hunt (IDM) wrote: > <snip> > > On Mar 14, 2016, at 14:13, John Bradley <ve7...@ve7jtb.com > > <mailto:ve7...@ve7jtb.com>> wrote: > >> Any client that has the resource and issuer hard coded probably > >> doesn't need discovery. > > We agree > > Yet any client that has hard coded a resource and 2 issuers doesn't need > discovery either but is vulnerable to the IDP mixup attack. > > I'd really like to see the two being addressed independently of each > other, regardless of the fact that a Discovery solution *could* solve the > IDP mixup attack as well. > > Hans. > > -- > Hans Zandbelt | Sr. Technical Architect > hzandb...@pingidentity.com | Ping Identity > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c8cd9a8b2e020444382a708d34c57a6b4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1dsstJfhduQ3mZERUx6%2fO3OE241RK7ataalg6RY6JmA%3d > > _______________________________________________ > 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
