Hi Mike,
(Adding Pamela in to get her thoughts as well. Jimmy I saw your response but she wasn't CC'ed?)
> On Oct 14, 2022, at 12:23 PM, Michael Sweet <msweet at msweet.org> wrote:
>> CAUTION: External Email
> Smith,
>> If I am reading this right it looks like they are saying we should treat different hostnames as different OAuth "realms", which seems to be an obvious answer. I would go slightly farther and say the combination of "oauth-authorization-server-uri" and "oauth-scope" should be used when caching authorization tokens for a given realm, and "oauth-authorization-server-uri", "oauth-scope", and "printer-uri" (or "server-uri") for access tokens (since token exchange yields device/service-specific tokens).
I agree these seem like some of the elements / attributes one of these profiles might contain.
If there is consensus on this in principle (we can work out the details if there are other elements / attributes that should be present instead or in addition to the ones above), I think there are two other questions that we need to address in our update to 5199.10 and friends:
a) Is there a need for UI to allow the user to select one of these profiles? Or is there even a possibility of ambiguity?
b) the general assumption is that these profiles are local to the client. I have to assume these tokens aren't transferrable between clients? If they are transferrable, and could be pulled in from a cloud account / interface, does OAuth 2.0 or OIDC define an endpoint that can be used to provide these? If not then that is veering into proprietary uniqueness and is outside the scope of our work, because I don't think the PWG wants to get into the business of defining additional OAuth 2.0 endpoints.
>>> > On Oct 13, 2022, at 4:37 PM, Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com> wrote:
> >
> >
> >
> >> On Oct 13, 2022, at 2:25 PM, Kennedy, Smith (Wireless & IPP Standards) via ipp <ipp at pwg.org> wrote:
> >>
> >> Signed PGP part
> >> CAUTION: External Email
> >>
> >> Hi there,
> >>
> >> I was having another discussion with HP's OAuth 2.0 folks over the last few days, and one of the things they are working on is guidance for the client on how it should or could manage the circumstance where the client device holds access tokens for multiple "realms" (i.e., work printing, home printing). If it was all just local information similar to Wi-Fi "profile" information maintained on the client, that would just be left up to the client's implementation.
> >>
> >> I found this page that seems to talk through some of these concepts.
> >
> >
> > Here's the link I meant to provide, which discussed it from an OIDC perspective: https://developer.okta.com/docs/guides/oin-oidc-multi-tenancy/main/#tenants-in-okta <https://developer.okta.com/docs/guides/oin-oidc-multi-tenancy/main/#tenants-in-okta>
> >
> >> I will continue to read, but wanted to share in case others have already developed plans or thoughts in this area, that we could leverage.
> >>
> >> Cheers,
> >>
> >> Smith
> >>
> >> /**
> >> Smith Kennedy
> >> HP Inc.
> >> */
> >>
> >>
> >
>> ________________________
> Michael Sweet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20221014/05c8616f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20221014/05c8616f/attachment.sig>