Seitz Ludwig <[email protected]> writes: > Seeing that the mechanism was introduced to bootstrap a client that > doesn't know which AS to talk to for a specific RS and given the > issues raised by John, what other options do we have that are more > secure? > > a.) A resource directory lookup? I'm not knowledgeable enough on RD to > answer whether that is more secure, but Steffi or Olaf or Carsten > should have more insight on this. > > b.) A callback to a trusted entity (say the client owner). The issue > here is that we have not defined any interactions for that entity yet. > > c.) John suggested something with DNS in the first mail. I have no > idea how this would work, John what did you have in mind there? > > For the draft I see two ways forward: > > 1.) Remove the whole discovery mechanism and just state that at this > point we assume that the knowledge of the right AS is > pre-configured/supplied out-of-band to the client. This leaves room > for future work that specifies an in-band method. > > 2.) Try to fix this (e.g. by specifying one of the methods a-c above). > > I do not have the time to do 2 so I clearly prefer option 1, but if > any of my co-authors can put in the work I'd be very glad.
The issue with options a and c is that they have the same privacy issues as the current solution. And, of course, they need a way for C to determine whether the used service (RD or DNS) is authorized to tell C which AS is supposed to issue access tokens for RS. And after that, C needs to check the very same things as before. Option b) is what OAuth does (by presenting the login screen to the user in front of the web browser). As said before, the current draft mimics exactly that behavior. But as the client is assumed to act autonomously, this client owner authorization process has been made upfront by configuring authorized AS's. Grüße Olaf _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
