George::
Again, I would want the transaction requirements to be part of the
API not part of the scope. In my mind, the authorization token
should convey the client is authorized to perform a set of actions
(capabilities) and then the API parameters define the exact
details of that particular transaction.
Torsten:: I understand your sentiments. How would you envision to ask
a user for consent about those details if this consent is required by law?
So it seems we are looking for two key aspects as it relates to the
transaction(s) and consent...
1. Require explicit user consent regarding the details of the transaction
2. Specify the details of the transaction
It seems the mapping of this to the term "scope" is because at the
authorization endpoint it's the "scopes" the user has to consent to.
However, we don't have to try and map this transactional functionality
into the existing more capability model of OAuth2.
Assuming that something like a "consent receipt" will be issued to the
user once they have consented... what about using a term more consistent
with consent? "transaction_consent" ? I'd even be fine with
"transaction_details" and then have the spec require that the user
consent to all information in the "transaction_details" object. Though I
suspect there are use cases where there are more details in the
transaction than for which the user needs to give consent. So that might
not be the best name.
At this point I'm probably splitting hairs:) Naming things is hard:)
On 4/30/19 6:39 AM, Torsten Lodderstedt wrote:
Am 26.04.2019 um 16:17 schrieb George Fletcher <gffle...@aol.com
<mailto:gffle...@aol.com>>:
On 4/25/19 1:54 PM, Torsten Lodderstedt wrote:
Am 25.04.2019 um 17:03 schrieb George Fletcher <gffle...@aol.com
<mailto:gffle...@aol.com>>:
A couple of thoughts...
1. It doesn't feel like these are scopes (at least not as scope is
defined by RFC 6749). It feels like they are more transaction
requirements.
What???s the difference? In my opinion, if you authorize a
transaction it???s the same. Moreover, in other use cases (account
information) it a complex requirement for a potentially long lasting
grant.
In both cases, they describe the request power of the token ==
it???s scope.
I guess I look at scope as "authorized to transfer" maybe something
like "authorized to transfer up to 10K". However the details of which
account to take the money from and the account of where to put the
money are not aspects of the scope but rather restrictions on the
transaction.
It may be fine to have a model where the client tells the AS what
transaction it wants to perform for the purpose of getting consent
from the user to perform that transaction... but I don't think the
details of the transaction should be considered scope(s).
For me.. scope is a capability the client is authorized to perform...
"send an Instant message", or "read a buddy list".
2. The schemas are going to be very ecosystem specific, correct?
API (e.g. all psd2 standards), ecosystem, single deployment - just
like ???traditional??? scope values
Again, I would want the transaction requirements to be part of the
API not part of the scope. In my mind, the authorization token should
convey the client is authorized to perform a set of actions
(capabilities) and then the API parameters define the exact details
of that particular transaction.
I understand your sentiments. How would you envision to ask a user for
consent about those details if this consent is required by law?
On 4/24/19 1:08 PM, Torsten Lodderstedt wrote:
Hi Sascha,
I see. I assume every element within the structured scope element to be an
independent scope (value) object and intended to use the name of that object as
kind of content type definition.
In my last example, the scope is defined as
"structured_scope":{
"sign":{
"credentialID":"qes_eidas",
"documentDigests":[
{
"hash":
"sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
"label":"Mobile Subscription Contract"
}
],
"hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
},
"payment":{
"type":"sepa-credit-transfer",
"instructedAmount":{
"currency":"EUR",
"amount":"123.50"
},
"debtorAccount":{
"iban":"DE40100100103307118608"
},
"creditorName":"Merchant123",
"creditorAccount":{
"iban":"DE02100100109307118603"
},
"remittanceInformationUnstructured":"new Smartphone"
}
This means ???sign" and ???payment" would determine the scheme of the
respective object.
What do you think?
best regards,
Torsten.
On 23. Apr 2019, at 17:14, Sascha Preibisch<saschapreibi...@gmail.com> wrote:
Hi Torsten!
If 'structured_scope' would become a generic field for application
specific content, I believe an indicator for the type of content would
be needed on the long run. That is what I meant my 'profile'. I hope
this helps!
Thank you,
Sascha
Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
<tors...@lodderstedt.net>:
Hi Sascha,
Am 22.04.2019 um 20:34 schrieb Sascha Preibisch<saschapreibi...@gmail.com>:
Thank you for the article, Torsten!
my pleasure :-)
I like that 'scope' is out of the game for these kinds of authorizations.
What I can see for the general use case is a required identifier
within the 'structures_scope' document that identifies the profile it
should be used for.
What does profile mean in this context?
best regards,
Torsten.
Thank you,
Sascha
Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
<tors...@lodderstedt.net>:
Hi all,
I just published an article about the subject
at:https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
I look forward to getting your feedback.
kind regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
