Thanks for the thoughts, Mike. For those not subscribed to GitHub updates, I finally added an issue about "phrasing".
The reason why we're going to take up this issue a little further along is that we need to get more perspective and distance, and treat naming as a holistic activity. For example, will "our client" end up simply being an OAuth client acting in a way that's conforming to our extension spec? Detailing this delta could be helpful.
And it's true that an UMA RS is also an OAuth client (for protection API purposes), which could cause us to think about other naming on that side, and/or other explanations in the spec.
Once we get through initial MPD-ish spec work (ideally in the next ~three weeks), we should be in a pretty good place to look at our remaining roadmap items and our overall issue backlog and start considering naming questions.
Eve Maler (sent from my iPad) | cell +1 425 345 6756
confusion around an UMA client vs. an OAuth client...
I find the term "UMA Client" particularly confusing, because the RS is also an OAuth2 client when it obtains a PAT. * trust elevation vs. claims gathering (interactive exclusively?)
To me, trust elevation implies increased level of assurance about the identity (i.e. just the subject identifier). While additional claims can increase your trust, and perhaps each claim can carry it's own assurance, I think seperating identity from claims would be more clear._______________________________________________WG-UMA mailing listWG-UMA@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/wg-uma