Yes that is an important Connect use case for Web server client registration. Also thought of as a typical web SP.
John B. On 2013-06-19, at 1:27 PM, Phil Hunt <[email protected]> wrote: > Justin > > Thanks for refreshing my mind. I forgot the web client case is acting on > behalf of many users. > > Phil > > On 2013-06-19, at 10:18, "Richer, Justin P." <[email protected]> wrote: > >> Your question seems to assume a one-to-one mapping between client and user, >> and that's not guaranteed to be the case. Think of an installed web >> application that's talking to an auth server, and that web application is >> going to talk to a number of different users. Those users can have multiple >> different language preferences. The human-readable fields are sent to the >> auth server so that the auth server can display them to the end user during >> the authorization screen and the application management screens. As such, it >> makes sense (and was requested by the working group at the last IETF) that a >> client can register its whole set of languages and the auth server picks the >> appropriate one to display to the user. >> >> It used to be the case that there was only a single value (unadorned with >> language tags) for things like client_name, and a client would've had to >> register itself multiple times to get at different languages. The Working >> Group decided that this was both too complicated and too error prone, so we >> adopted (and adapted) the OpenID Connect method for flagging languages. This >> allows a client to register once for all users and all language types. It >> wouldn't make sense (and it would cause serious race conditions) for a >> client to try and switch languages mid-stream for different users. >> >> On the server side, if your auth server wants to handle localized values >> appropriately, it will need to parse and manage multiple tagged values for >> each human readable field. However, we're recommending that clients always >> send the bare field with an internationalized value (i.e., it's got the best >> chance of being read by the largest audience for the client/auth server, a >> good default if you will), so you can fairly safely just look for and use >> the bare fields in most cases. >> >> Hope this clears things up. If you have any recommendations for how to make >> this intended usage clearer, I'd be happy to accept some new suggested text. >> >> Thanks, >> >> -- Justin >> >> On Jun 19, 2013, at 1:05 PM, Phil Hunt <[email protected]> >> wrote: >> >>> I am looking over the section on Human Readable Client Metadata and am a >>> bit confused as it pertains to the rest of the specification and the >>> implications for service providers. >>> >>> Is it the intention that even single-valued client metadata may have >>> multiple localized values? Or, is the assumption that a client would >>> signal its preferred language and that ALL metadata values have only ONE >>> localization at a time? >>> >>> I started considering this when I got to the section discussing things like >>> having client_name#ja-Jpan-JP and client_name#en. >>> >>> Would be a lot simpler to have preferredLanguage be part of the client >>> schema and assume that all human readable fields have been localized by the >>> client. It seems to me to be more complex if every client registers its >>> entire set of language translations for each piece of metadata if the user >>> will only ever use one at a time. Why track all variants? >>> >>> My thought is that in the case of OAuth client interactions, all language >>> localization is to drive the interface for the personal use of the user at >>> hand. We don't have the case as we do in directories where an english >>> language person might be looking up information about a Japanese person. >>> >>> That said, it would become a normal for a client to trigger a registration >>> "update" event for the client to update its metadata when the client >>> detected a change in language by the user. E.g. from en to ja-JPan-JP. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> [email protected] >>> >>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
