On Fri, 17 May 2024, at 15:04, Aaron Parecki wrote:
> I agree this is a useful profile for this ecosystem. I would be happy to help
> with this document, as well as help prepare a presentation on this at the
> next IETF meeting.
Thanks Aaron, that would be much appreciated.
On Sat, 18 May 2024,
Hi and thanks for the feedback!
Here are my thoughts on the comments:
Should at least one of ttl and exp be required? Why is ttl not listed for
CBOR? Are both mechanisms needed?
- I would say no - right now we require “iat” which allows a relying party to
make an informed decision on wh
Thanks for 1 and 2, but 3 is still the question that I feel is unanswered.
Can you walk through a concrete implementation use case that highlights how
exactly the RO would delegate this access?
It isn't clear for me how the RO would actually dynamically determine what
to do here without:
- The
Yes, it can be managed through some client specific policies at AS, however, as
already stated in the 6749 the method of arranging this policy is not
specified. The proposed draft describes how resource owner can dynamically
manage delegation for third party client(s) so that no additional poli
Let me try to answer those questions:
1. The RO can still access its own resources by requesting token using
client_credentials grant as per standard OAuth;
2. Typically the scopes will be specified during RO client registration;
3. This will depend on what type of access the
Yeah this just sounds like the client credentials grant with some policy at
the AS. There's no limitation that the client credentials grant is only
used to access resources owned by the client. From 6749:
The client can request an access token using only its client
credentials (or other supp
Okay but that just creates more unanswered questions. Now we are at three
for this part:
1. What does an RO obtaining scopes to its own resource mean
2. How does it obtain scopes to its own resource
3. How does the RO decide which scopes to delegate to the TP client?
On Sun, May 19, 2
The idea is that the resource owner client can delegate some or all of its own
scopes. For example, if the resource owner client can obtain “read” and “write”
scopes on its own resource, it can decide to delegate “read” scope for that
resource to the third party client, but not the “write” scope
Hmmm, interesting. How does the first-party client decide which scopes to
grant to the third party service?
On Sun, May 19, 2024 at 1:52 PM Igor Janicijevic wrote:
> Maybe I failed to set the context here, as you rightly pointed out. This
> new proposed flow is for B2B or system to system intera
Maybe I failed to set the context here, as you rightly pointed out. This new
proposed flow is for B2B or system to system interactions only, i.e. no user
agents (browsers) and no humans (end users) are involved, so there are no user
agent redirects…
In standard OAuth, for system to system acces
Maybe let's separate those two things for a second:
1. Third party acquiring token to access RS
2. RO revoking token generated for the Third Party client
For #1. I'd be interested to know how this is any different from an OAuth
Client that wants to access RS on behalf of the RO. In this
Hi Warren,
There are four parties in this flow: the resource owner client, the third party
client, the resource server and the AS. The token issued by AS to third party
client is not presented to the resource owner client – it is only presented to
the resource server when third party client is
Interesting draft. Having standard defined scopes for the most common operations of the underlying protocols is crucial, as Lisa points out. In OpenID Connect this was indispensable in making the whole thing complete, useful and interoperable. But where should these scopes get defined, if this is a
But the AS is already governing the access between clients, so at the
surface at least I'm not able to wrap my head around your counterargument.
Also this:
> Also, the resource owner client cannot easily revoke tokens issued to
> third party clients that it federates access with.
Why not? It is
Yes, technically you can use token exchange to federate access but you have to
manage AS policy for each combination of clients that need to exchange tokens.
Also, the resource owner client cannot easily revoke tokens issued to third
party clients that it federates access with.
This draft tries
Events without label "editorial"
Issues
--
* oauth-wg/oauth-transaction-tokens (+2/-1/💬1)
2 issues created:
- Deployment models for the Transaction Token Service (by gffletch)
https://github.com/oauth-wg/oauth-transaction-tokens/issues/96
- Define discovery metadata for support of t
16 matches
Mail list logo
