Hi George,
For single-page-apps the client registration endpoint may return the client
secret in the form of cookies with the HttpOnly and secure flags set.
Javascript will not be able to access the client secret and the front-end
developer does not have to fiddle with the secret. If the user deletes the
cookies, the client re-registers with the AS.
-Igor
On Wed, Oct 6, 2021 at 7:30 PM George Fletcher <george.fletcher(a)yahooinc.com>
wrote:
> For single-page-apps there is also DPoP [
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-04] which
> provides some similar capabilities using ephemeral keys. The issue I see
> with DCR and SPAs is maintaining the keys in the browser in a persistent
> way.
>
> On Wed, Oct 6, 2021 at 7:11 AM Igor Zboran <izboran(a)gmail.com> wrote:
>
>> Hi everyone,
>>
>> Please take a look at
>> https://github.com/uma-email/poc#protected-dynamic-client-registration
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_uma-2Demail…>
>> .
>>
>> This may solve the single page applications and native applications
>> problem with client secrets. I mean, the client is public with respect to
>> the IdP, and at the same time – after dynamic registration – confidential
>> with respect to the AS.
>>
>> Regards
>>
>> -Igor
>> _______________________________________________
>> WG-UMA mailing list
>> WG-UMA(a)kantarainitiative.org
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__kantarainitiative.org_…
>>
>
Hi everyone,
Please take a look at
https://github.com/uma-email/poc#protected-dynamic-client-registration.
This may solve the single page applications and native applications problem
with client secrets. I mean, the client is public with respect to the IdP,
and at the same time – after dynamic registration – confidential with
respect to the AS.
Regards
-Igor
https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-16
MinutesRoll call
Quorum was NOT reached.
Approve minutes
- Approve minutes of UMA telecon 2021-09-09
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-09>
Deferred
Correlated Authorization
https://github.com/uma-email/poc
Today in UMA can push the token, addition is binding the ticket to the
pushed token
There's nothing bad about this claim token profile, not sure what the
specific use-case or outcome it tries to create
What is the motivation for needing the correlation? Is there a specific
outcome the correlation creates over 'ticket challenge-less' claims pushing?
- not allowing RpQ token reuse. Is this beneficial? is it tied to the
first use of that token and require re-issuance if the AS needs_info
- non-interactive RqP id assertion
OAuth vs UMA content
Since this a common information request, could we create some good standard
content/position?
EIC Points:
OAuth
- Tokens issued to a Resource Owner at a Client
- Communication between Resource Server and Authorization Server is out
of scope
- this necessarily 'narrows' the ecosystem, since the RS and AS need
to agree ahead of time on authorization details
- usually RS/AS are in the same domain (eg TLD)* Is this something
that OAuth says or is it what people naturally implement?*
There are OAuth extensions that drive to UMA-like outcomes, such as Token
Exchange <https://www.rfc-editor.org/rfc/rfc8693.html> which allows a
Client to get a token representing another party. Or GNAP which takes a
bunch of UMA + OAuth features and derives a new authorization protocol.
Typically considered as 1 RS and 1 AS, with many RPs/clients
UMA
- Tokens issued to a Requesting Party at a Client
- Defines API between RS and AS for: resource registration, permission
ticket creation and introspection
- There can be "many of everything" not just Clients ← this is a "hard"
concept for people to grasp at times
People ofter struggle with the 'nicknamed tokens', understanding they are
access token which specific scopes/purposes. PCT has often been a hard one
to understand, not widely implemented today because of this?
UMA Outcomes:
- RO to RqP delegation,
- decouple consent(policy settings, consent as pre-condition for any
tokens/grants) from transaction(token issuance), can happen ahead of time
or just in time
- AS Discovery and RO selected AS,
- Request and grant for specific fine-grained resources, doesn't look at
an entire RS as the resource but allows arbitrarily small resource
registration
UMA is very flexible and comprehensive, which creates it's own set of
interoperability challenges. Requires interop/ecosystem profiles which
immediately undercut the UMA goal of wide-ecosystem.
- Even client registration at the AS is challenging. UMA implies that
it's dynamic since 'any client can be used', however this isn't in wide
practice today (most clients today are pre-registered)
- culmination of different barriers (technical, common practice,
understanding) that make UMA difficult to use in practice
Trust Registry helps with decentralization and creating a more informed AS.
More granularity around the purpose, state for authorization and checking
for changes (new role for PCT?) Captures, AS endpoint, purpose, scope of
permissions. There will be many of them, ideally not too many for each RS.
How do they interact? Regional/local collaboration, and then combining
regional networks with congruent code of practices to create a wider
ecosystem.
Topic for future weeks: outcome of user stories discussion, PDP
architecture includes the concept, TOIP/SSI are starting to define this
ecosystem function
Topic for future weeks: ANCR records update, Privacy as Expected.
AOB
https://www.ontario.ca/page/consultation-policy-framework-ontarios-digital-…
Feel
free to submit comments to Ontario about the DI strategy
Alec will be away next week
Attendees
As of October 26, 2020, quorum
<http://kantarainitiative.org/confluence/display/uma/Participant+Roster> is
5 of 9. (Michael, Domenico, Peter, Sal, Thomas, Andi, Alec, Eve, Steve)
Voting:
1. Alec
2. Sal
Non-voting participants:
1. Zhen
2. Ian
Regrets:
1. Eve
<https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2021-09-16>
Hi all,
I have been thinking for a long time how to convey information about the
user from an identity provider to an authorization server, especially
across security domain boundaries. This is difficult to implement because
OAuth2, OIDC and UMA are single-authority protocols. That's why I tried to
extend the UMA protocol to a dual-authority protocol. Please find a short
draft proposal here: https://github.com/uma-email/poc
I would be very interested to know if this is the right way to do it and
what you think about this idea.
Disclaimer: Although I present the idea of the correlated authorization as
a new protocol, if adopted and refined by the working group, it could be
referred to as the UMA wide ecosystem.
Regards
-Igor
