Warren, I'm not familiar with your IDP product, but I'm guessing it works the same way as most commercial services today, which means it probably requires that the app developer registers for credentials at the IDP before being able to send a user through a flow and get a JWT. This doesn't work for the "open web" or "bring your own IDP" scenario where apps and IDPs don't necessarily have a prior relationship.
So to answer your question, working backwards, can I build a website that gets a JWT from your authorization server without me as the developer having to register a client ID? Assume the user would provide the details of their authorization server to my website on the first visit. (How they provide this is out of scope for this question, but could be entering a URL, webfinger discovery from email, or FedCM) Aaron On Tue, Jan 21, 2025 at 12:14 PM Warren Parad <wparad= 40rhosys...@dmarc.ietf.org> wrote: > I'm not really following. Maybe let's start at the end and work ourselves > backwards. As an Identity Provider today, we generate JWTs for our users > that applications can use. Users log in to applications via our > Authorization Server and get application specific JWTs. Based on your > suggestion how does the result JWT different from the one that we are > generating for the user+application today? > > On Tue, Jan 21, 2025 at 9:02 PM Phillip Hallam-Baker < > ph...@hallambaker.com> wrote: > >> On Tue, Jan 21, 2025 at 2:43 PM Warren Parad <wpa...@rhosys.ch> wrote: >> >>> The only thing lacking is a base of authentication service providers >>>> that are willing to give users control. >>> >>> >>> As someone who works for one of those "authentication service >>> providers", what exactly would we need to support that we don't already? >>> >> >> I am writing a draft. The short answer is almost nothing. But not nothing. >> >> The longer answer is that we need to have: >> >> 1) A detailed explanation that puts ALL the information needed to >> implement against the profile in one place. I am working on an Internet >> draft to do exactly that. >> >> 2) A discussion of how to best present the scheme as something whose >> primary purpose is as an authentication provider rather than an account >> with one social media property that can also be used elsewhere. >> >> 3) A discussion of how to use the DNS handles to enable end-to-end secure >> messaging. If Bob is reading a comment by Alice under @alice.example.com, >> that is the handle he is likely to want to use to message her. >> >> 4) A discussion about what else we might want a DNS handle provider to >> support. I have a prototype running that extends to supporting the IoT >> requirements raised in SETTLE. >> >> Right now, we have 'a' way to do this which is not necessarily the best >> way or the way that allows us to grow in all the ways we might want in the >> future. >> >> I have a history of being able to market protocols and get them into >> widespread use. I haven't always been successful but have more successes >> than failures and I think I know what it takes to make DNS Handles widely >> used, which businesses I need to approach, etc. etc. >> >> The reason I am raising this here now, is that before I go round to the >> DNS registrars (and their affiliates) and the VPN providers and such to say >> this is the thing to do, I want to make sure we have everything straight at >> a technical level so we are all on the same page. >> >> >> _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
