Re: [OAUTH-WG] Dynamic Scopes
Hi George, I‘m intrigued by the idea to encapsulate scope preparation and resource identification into the RS. This seems to be a viable pattern to implement transaction-oriented authorization. I‘m not sure whether this justifies the implementation of UMA 2.0 in AS (additional grant types, claims interaction endpoint, endpoints for RS/AS interactions), RS and client. I think the basic idea could also be utilized by preparing a transaction-specific scope value when the client calls the RS for the first time. The client could then pass this value in the scope parameter as part of a standard authz code grant type authz request. Does this sound reasonable? best regards, Torsten. > Am 27.06.2018 um 12:13 schrieb George Fletcher : > > Yes, that is the basic idea and matches the UMA flow. I think some profiling > of UMA is required but may be good place to start. > > Thanks, > George > > -- > Identity Standards Architect > Identity Engineering > Oath > >> On Jun 27, 2018, at 12:22 PM, Torsten Lodderstedt >> wrote: >> >> Hi George, >> >> thanks a lot for investing the time to assemble this flow description! >> >> If I got it right the idea is to move the definition of the required >> permissions (scope) >> of the requested access token to the interaction between signing service and >> authz service >> when the permission ticket is obtained as reaction to the attempt of the >> client (the insurance >> company) to sign a document. So the client does not need to know what scope >> to request. >> It instead uses the permission ticket (minted by the RS and the AS) to >> request the needed >> permissions. >> >> Is that correct? >> >> best regards, >> Torsten. >> >>> Am 24.06.2018 um 15:01 schrieb George Fletcher : >>> >>> Not sure I have the flow exactly correct... here is an attempt to define a >>> flow based on UMA. It's a little difficult to label which flows are which >>> parts of the specs. Specifically I am using... >>> >>> https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html >>> https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-05.html >>> >>> If you want the see the image... take the following text and load it into >>> https://www.websequencediagrams.com/ >>> >>> title Signing Sequence >>> >>> participant "Browser" as B >>> participant "Insurer" as I >>> participant "Signer" as S >>> participant "Bank\n(UMA AS)" as A >>> >>> B->I: complete process >>> I->S: sign doc\n(required params) >>> S->A: permission req\n(what the signer needs) >>> A->S: permission ticket >>> S->I: Not authorized\n(AS + permission tckt) >>> I->A: request RPT\n(permission tckt) >>> A->I: need_info >>> I-->B: redirect >>> B->A: claims interaction endpoint >>> A->B: user verification & consent >>> B->A: user meets required claims >>> A-->B: redirect >>> B->I: user met claimns\n(permission tckt) >>> I->A: request RPT\n(permission tckt) >>> A->I: RPT issued >>> I->S: sign doc\n(RPT) >>> S->A: introspect\n(RPT) >>> A->S: permissions\n(required params) >>> S->I: Signed doc >>> >>> >>> On 6/24/18 4:27 AM, Torsten Lodderstedt wrote: Hi George, how is the dynamic nature (hash) of the authorization request handled in your solution? Note: the signing service is not provided by the insurance company but a third party, a sol-called trusted service provider. The insurance company as the client in this flow sends the request to this provider. best regards, Torsten. Am 23.06.2018 um 21:07 schrieb George Fletcher : > Thanks Torsten. > > I think I have a solution :) Just to make sure I have the flow correct > > Assumption: Using a mobile client > > 1. User (using their mobile client) attempts to sign a document with the > insurance company > 2. Insurance company redirects the user to their Bank asking for identity > proof, and signing of specific documents > 3. User interacts with Bank to get authorization for the specific > transaction > 4. Mobile client submits request to insurance company using token that is > specific to the user, document etc. > > This is effectively the UMA 2.0 flow [1] > > 1. Mobile client attempts to invoke resource at the insurance company > 2. Insurance company registers the request with UMA AS (the bank in this > case) and gets a permissions ticket > 3. Insurance company instructs mobile client to contact the bank > 4. Mobile client contacts the bank specifying the permissions ticket > 5. User meets banks requirements for the specific transaction (claims > interaction) > 6. Bank issues mobile client the RPT (token) > 7. Mobile client invokes resource at insurance company with RPT > > Note that the insurance company can specify the necessary bits that need > to be in the token when it interacts with the Bank (as the UMA AS). >>>
Re: [OAUTH-WG] Dynamic Scopes
Yes, that is the basic idea and matches the UMA flow. I think some profiling of UMA is required but may be good place to start. Thanks, George -- Identity Standards Architect Identity Engineering Oath > On Jun 27, 2018, at 12:22 PM, Torsten Lodderstedt > wrote: > > Hi George, > > thanks a lot for investing the time to assemble this flow description! > > If I got it right the idea is to move the definition of the required > permissions (scope) > of the requested access token to the interaction between signing service and > authz service > when the permission ticket is obtained as reaction to the attempt of the > client (the insurance > company) to sign a document. So the client does not need to know what scope > to request. > It instead uses the permission ticket (minted by the RS and the AS) to > request the needed > permissions. > > Is that correct? > > best regards, > Torsten. > >> Am 24.06.2018 um 15:01 schrieb George Fletcher : >> >> Not sure I have the flow exactly correct... here is an attempt to define a >> flow based on UMA. It's a little difficult to label which flows are which >> parts of the specs. Specifically I am using... >> >> https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html >> https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-05.html >> >> If you want the see the image... take the following text and load it into >> https://www.websequencediagrams.com/ >> >> title Signing Sequence >> >> participant "Browser" as B >> participant "Insurer" as I >> participant "Signer" as S >> participant "Bank\n(UMA AS)" as A >> >> B->I: complete process >> I->S: sign doc\n(required params) >> S->A: permission req\n(what the signer needs) >> A->S: permission ticket >> S->I: Not authorized\n(AS + permission tckt) >> I->A: request RPT\n(permission tckt) >> A->I: need_info >> I-->B: redirect >> B->A: claims interaction endpoint >> A->B: user verification & consent >> B->A: user meets required claims >> A-->B: redirect >> B->I: user met claimns\n(permission tckt) >> I->A: request RPT\n(permission tckt) >> A->I: RPT issued >> I->S: sign doc\n(RPT) >> S->A: introspect\n(RPT) >> A->S: permissions\n(required params) >> S->I: Signed doc >> >> >> >>> On 6/24/18 4:27 AM, Torsten Lodderstedt wrote: >>> Hi George, >>> >>> how is the dynamic nature (hash) of the authorization request handled in >>> your solution? >>> >>> Note: the signing service is not provided by the insurance company but a >>> third party, a sol-called trusted service provider. The insurance company >>> as the client in this flow sends the request to this provider. >>> >>> best regards, >>> Torsten. >>> >>> Am 23.06.2018 um 21:07 schrieb George Fletcher : >>> Thanks Torsten. I think I have a solution :) Just to make sure I have the flow correct Assumption: Using a mobile client 1. User (using their mobile client) attempts to sign a document with the insurance company 2. Insurance company redirects the user to their Bank asking for identity proof, and signing of specific documents 3. User interacts with Bank to get authorization for the specific transaction 4. Mobile client submits request to insurance company using token that is specific to the user, document etc. This is effectively the UMA 2.0 flow [1] 1. Mobile client attempts to invoke resource at the insurance company 2. Insurance company registers the request with UMA AS (the bank in this case) and gets a permissions ticket 3. Insurance company instructs mobile client to contact the bank 4. Mobile client contacts the bank specifying the permissions ticket 5. User meets banks requirements for the specific transaction (claims interaction) 6. Bank issues mobile client the RPT (token) 7. Mobile client invokes resource at insurance company with RPT Note that the insurance company can specify the necessary bits that need to be in the token when it interacts with the Bank (as the UMA AS). [There might be some profiling required here] I think it's worth exploring whether UMA will solve this use case. Thanks, George [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html > On 6/23/18 3:43 AM, Torsten Lodderstedt wrote: >> Am 22.06.2018 um 23:08 schrieb George Fletcher : >> >> I would think that the scope issued to the refresh_token could represent >> the category or class of authorizations the refresh_token should be able >> to perform. For example, the kind of transactions that can be bound to >> access tokens. The scope issued into the access_token could be one of >> the "parameterized" ones. But maybe I'm not fully understanding the use >> case :) > Let me try to explain ;-) > > The client is an issuance company wanti
Re: [OAUTH-WG] Dynamic Scopes
Hi George, thanks a lot for investing the time to assemble this flow description! If I got it right the idea is to move the definition of the required permissions (scope) of the requested access token to the interaction between signing service and authz service when the permission ticket is obtained as reaction to the attempt of the client (the insurance company) to sign a document. So the client does not need to know what scope to request. It instead uses the permission ticket (minted by the RS and the AS) to request the needed permissions. Is that correct? best regards, Torsten. > Am 24.06.2018 um 15:01 schrieb George Fletcher : > > Not sure I have the flow exactly correct... here is an attempt to define a > flow based on UMA. It's a little difficult to label which flows are which > parts of the specs. Specifically I am using... > > https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html > https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-05..html > > If you want the see the image... take the following text and load it into > https://www.websequencediagrams.com/ > > title Signing Sequence > > participant "Browser" as B > participant "Insurer" as I > participant "Signer" as S > participant "Bank\n(UMA AS)" as A > > B->I: complete process > I->S: sign doc\n(required params) > S->A: permission req\n(what the signer needs) > A->S: permission ticket > S->I: Not authorized\n(AS + permission tckt) > I->A: request RPT\n(permission tckt) > A->I: need_info > I-->B: redirect > B->A: claims interaction endpoint > A->B: user verification & consent > B->A: user meets required claims > A-->B: redirect > B->I: user met claimns\n(permission tckt) > I->A: request RPT\n(permission tckt) > A->I: RPT issued > I->S: sign doc\n(RPT) > S->A: introspect\n(RPT) > A->S: permissions\n(required params) > S->I: Signed doc > > > >> On 6/24/18 4:27 AM, Torsten Lodderstedt wrote: >> Hi George, >> >> how is the dynamic nature (hash) of the authorization request handled in >> your solution? >> >> Note: the signing service is not provided by the insurance company but a >> third party, a sol-called trusted service provider. The insurance company as >> the client in this flow sends the request to this provider. >> >> best regards, >> Torsten. >> >> Am 23.06.2018 um 21:07 schrieb George Fletcher : >> >>> Thanks Torsten. >>> >>> I think I have a solution :) Just to make sure I have the flow correct >>> >>> Assumption: Using a mobile client >>> >>> 1. User (using their mobile client) attempts to sign a document with the >>> insurance company >>> 2. Insurance company redirects the user to their Bank asking for identity >>> proof, and signing of specific documents >>> 3. User interacts with Bank to get authorization for the specific >>> transaction >>> 4. Mobile client submits request to insurance company using token that is >>> specific to the user, document etc. >>> >>> This is effectively the UMA 2.0 flow [1] >>> >>> 1. Mobile client attempts to invoke resource at the insurance company >>> 2. Insurance company registers the request with UMA AS (the bank in this >>> case) and gets a permissions ticket >>> 3. Insurance company instructs mobile client to contact the bank >>> 4. Mobile client contacts the bank specifying the permissions ticket >>> 5. User meets banks requirements for the specific transaction (claims >>> interaction) >>> 6. Bank issues mobile client the RPT (token) >>> 7. Mobile client invokes resource at insurance company with RPT >>> >>> Note that the insurance company can specify the necessary bits that need to >>> be in the token when it interacts with the Bank (as the UMA AS). [There >>> might be some profiling required here] >>> >>> I think it's worth exploring whether UMA will solve this use case. >>> >>> Thanks, >>> George >>> >>> [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html >>> On 6/23/18 3:43 AM, Torsten Lodderstedt wrote: > Am 22.06.2018 um 23:08 schrieb George Fletcher : > > I would think that the scope issued to the refresh_token could represent > the category or class of authorizations the refresh_token should be able > to perform. For example, the kind of transactions that can be bound to > access tokens. The scope issued into the access_token could be one of the > "parameterized" ones. But maybe I'm not fully understanding the use case > :) Let me try to explain ;-) The client is an issuance company wanting the customer to electronically sign a new contract (legally binding!). Signing in the end means to send a request containing the hash of the document to an API. The API will respond with an CM/S Object containing signature, certificate etc that the client will embedded in the contract document (typical PDF). We want the user to authorize the signing request using their bank as IDP/AS. Therefore t
Re: [OAUTH-WG] Dynamic Scopes
Hi George, how is the dynamic nature (hash) of the authorization request handled in your solution? Note: the signing service is not provided by the insurance company but a third party, a sol-called trusted service provider. The insurance company as the client in this flow sends the request to this provider. best regards, Torsten. > Am 23.06.2018 um 21:07 schrieb George Fletcher : > > Thanks Torsten. > > I think I have a solution :) Just to make sure I have the flow correct... > > Assumption: Using a mobile client > > 1. User (using their mobile client) attempts to sign a document with the > insurance company > 2. Insurance company redirects the user to their Bank asking for identity > proof, and signing of specific documents > 3. User interacts with Bank to get authorization for the specific transaction > 4. Mobile client submits request to insurance company using token that is > specific to the user, document etc. > > This is effectively the UMA 2.0 flow [1] > > 1. Mobile client attempts to invoke resource at the insurance company > 2. Insurance company registers the request with UMA AS (the bank in this > case) and gets a permissions ticket > 3. Insurance company instructs mobile client to contact the bank > 4. Mobile client contacts the bank specifying the permissions ticket > 5. User meets banks requirements for the specific transaction (claims > interaction) > 6. Bank issues mobile client the RPT (token) > 7. Mobile client invokes resource at insurance company with RPT > > Note that the insurance company can specify the necessary bits that need to > be in the token when it interacts with the Bank (as the UMA AS). [There might > be some profiling required here] > > I think it's worth exploring whether UMA will solve this use case. > > Thanks, > George > > [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html > >> On 6/23/18 3:43 AM, Torsten Lodderstedt wrote: >> >>> Am 22.06.2018 um 23:08 schrieb George Fletcher : >>> >>> I would think that the scope issued to the refresh_token could represent >>> the category or class of authorizations the refresh_token should be able to >>> perform. For example, the kind of transactions that can be bound to access >>> tokens. The scope issued into the access_token could be one of the >>> "parameterized" ones. But maybe I'm not fully understanding the use case :) >> Let me try to explain ;-) >> >> The client is an issuance company wanting the customer to electronically >> sign a new contract (legally binding!). Signing in the end means to send a >> request containing the hash of the document to an API. The API will respond >> with an CM/S Object containing signature, certificate etc that the client >> will embedded in the contract document (typical PDF). >> >> We want the user to authorize the signing request using their bank as >> IDP/AS. Therefore the client sends the OAuth authorization request to the >> AS. The actual signing request needs to be bound to client, user AND hash >> (document) in order to prevent fraud. Regulation (eIDAS) requires to always >> demonstrate the sole control of the user over the whole process. The AS >> therefore binds (scopes) the access token to exactly this single >> document/signing request. If the client wants the user to sign another >> document, it needs to got through the whole process again. >> >> One could think about a general signing permission represented by a refresh >> token, but not in the high assurance level cases I‘m looking into.. >> >> Hope that helps, >> Torsten. >> >> > smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Dynamic Scopes
Thanks Torsten. I think I have a solution :) Just to make sure I have the flow correct... Assumption: Using a mobile client 1. User (using their mobile client) attempts to sign a document with the insurance company 2. Insurance company redirects the user to their Bank asking for identity proof, and signing of specific documents 3. User interacts with Bank to get authorization for the specific transaction 4. Mobile client submits request to insurance company using token that is specific to the user, document etc. This is effectively the UMA 2.0 flow [1] 1. Mobile client attempts to invoke resource at the insurance company 2. Insurance company registers the request with UMA AS (the bank in this case) and gets a permissions ticket 3. Insurance company instructs mobile client to contact the bank 4. Mobile client contacts the bank specifying the permissions ticket 5. User meets banks requirements for the specific transaction (claims interaction) 6. Bank issues mobile client the RPT (token) 7. Mobile client invokes resource at insurance company with RPT Note that the insurance company can specify the necessary bits that need to be in the token when it interacts with the Bank (as the UMA AS). [There might be some profiling required here] I think it's worth exploring whether UMA will solve this use case. Thanks, George [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html On 6/23/18 3:43 AM, Torsten Lodderstedt wrote: Am 22.06.2018 um 23:08 schrieb George Fletcher : I would think that the scope issued to the refresh_token could represent the category or class of authorizations the refresh_token should be able to perform. For example, the kind of transactions that can be bound to access tokens. The scope issued into the access_token could be one of the "parameterized" ones. But maybe I'm not fully understanding the use case :) Let me try to explain ;-) The client is an issuance company wanting the customer to electronically sign a new contract (legally binding!). Signing in the end means to send a request containing the hash of the document to an API. The API will respond with an CM/S Object containing signature, certificate etc that the client will embedded in the contract document (typical PDF). We want the user to authorize the signing request using their bank as IDP/AS. Therefore the client sends the OAuth authorization request to the AS. The actual signing request needs to be bound to client, user AND hash (document) in order to prevent fraud. Regulation (eIDAS) requires to always demonstrate the sole control of the user over the whole process. The AS therefore binds (scopes) the access token to exactly this single document/signing request. If the client wants the user to sign another document, it needs to got through the whole process again. One could think about a general signing permission represented by a refresh token, but not in the high assurance level cases I‘m looking into. Hope that helps, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Dynamic Scopes
Hi Nat, I thought the same when we started this endeavor. What I learned is this has privacy/confidentiality implications since the AS learns the content of the document. For example, sending the document to a staging API also requires a consent of the user (given prior to the data transfer!) in case PII is contained in the document. Moreover, depending on the format of the document, the AS needs different viewers, which increases complexity. So the current concept (which is also standard practice in this sector) is the client shows the prepared and signed document before and after the signing process and is legally obliged to do it correctly. The AS is responsible for providing the signing service with verified person data and captures the user‘s intent to sign. Both require consent. best regards, Torsten. > Am 23.06.2018 um 15:13 schrieb n-sakimura : > > Torsten, > > For the digital signature case, I feel a bit uneasy to sign the hash that was > sent by the client. The signing mechanism, a bank in this case, should > display what is being signed to the user before the user makes a signature. > The staging strategy works here as well. The client sends the signed document > to the staging server and the bank verifies the signature and shows the > document to the user, where the user can view the document and when he > decides to sign it, the signature over the document’s hash will be made so > that it will result in a mutually signed document. > > Best, > > Nat > > Nat Sakimura > このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、送信者にご連絡のうえ、このメールを削除してくださいますようお願い申し上げます。 > > PLEASE READ：This e-mail is confidential and intended for the named recipient > only. If you are not an intended recipient, please notify the sender and > delete this e-mail. > From: OAuth on behalf of Torsten Lodderstedt > > Sent: Saturday, June 23, 2018 3:43:50 AM > To: George Fletcher > Cc: Brian Campbell; oauth > Subject: Re: [OAUTH-WG] Dynamic Scopes > > > > > Am 22.06.2018 um 23:08 schrieb George Fletcher : > > > > I would think that the scope issued to the refresh_token could represent > > the category or class of authorizations the refresh_token should be able to > > perform. For example, the kind of transactions that can be bound to access > > tokens. The scope issued into the access_token could be one of the > > "parameterized" ones. But maybe I'm not fully understanding the use case :) > > Let me try to explain ;-) > > The client is an issuance company wanting the customer to electronically sign > a new contract (legally binding!). Signing in the end means to send a request > containing the hash of the document to an API. The API will respond with an > CM/S Object containing signature, certificate etc that the client will > embedded in the contract document (typical PDF). > > We want the user to authorize the signing request using their bank as > IDP/AS.. Therefore the client sends the OAuth authorization request to the > AS. The actual signing request needs to be bound to client, user AND hash > (document) in order to prevent fraud. Regulation (eIDAS) requires to always > demonstrate the sole control of the user over the whole process. The AS > therefore binds (scopes) the access token to exactly this single > document/signing request. If the client wants the user to sign another > document, it needs to got through the whole process again. > > One could think about a general signing permission represented by a refresh > token, but not in the high assurance level cases I‘m looking into. > > Hope that helps, > Torsten. > > smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Dynamic Scopes
Torsten, For the digital signature case, I feel a bit uneasy to sign the hash that was sent by the client. The signing mechanism, a bank in this case, should display what is being signed to the user before the user makes a signature. The staging strategy works here as well. The client sends the signed document to the staging server and the bank verifies the signature and shows the document to the user, where the user can view the document and when he decides to sign it, the signature over the document’s hash will be made so that it will result in a mutually signed document. Best, Nat Nat Sakimura このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、送信者にご連絡のうえ、このメールを削除してくださいますようお願い申し上げます。 PLEASE READ：This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. From: OAuth on behalf of Torsten Lodderstedt Sent: Saturday, June 23, 2018 3:43:50 AM To: George Fletcher Cc: Brian Campbell; oauth Subject: Re: [OAUTH-WG] Dynamic Scopes > Am 22.06.2018 um 23:08 schrieb George Fletcher : > > I would think that the scope issued to the refresh_token could represent the > category or class of authorizations the refresh_token should be able to > perform. For example, the kind of transactions that can be bound to access > tokens. The scope issued into the access_token could be one of the > "parameterized" ones. But maybe I'm not fully understanding the use case :) Let me try to explain ;-) The client is an issuance company wanting the customer to electronically sign a new contract (legally binding!). Signing in the end means to send a request containing the hash of the document to an API. The API will respond with an CM/S Object containing signature, certificate etc that the client will embedded in the contract document (typical PDF). We want the user to authorize the signing request using their bank as IDP/AS.. Therefore the client sends the OAuth authorization request to the AS. The actual signing request needs to be bound to client, user AND hash (document) in order to prevent fraud. Regulation (eIDAS) requires to always demonstrate the sole control of the user over the whole process. The AS therefore binds (scopes) the access token to exactly this single document/signing request. If the client wants the user to sign another document, it needs to got through the whole process again. One could think about a general signing permission represented by a refresh token, but not in the high assurance level cases I‘m looking into. Hope that helps, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Dynamic Scopes
> Am 22.06.2018 um 23:08 schrieb George Fletcher : > > I would think that the scope issued to the refresh_token could represent the > category or class of authorizations the refresh_token should be able to > perform. For example, the kind of transactions that can be bound to access > tokens. The scope issued into the access_token could be one of the > "parameterized" ones. But maybe I'm not fully understanding the use case :) Let me try to explain ;-) The client is an issuance company wanting the customer to electronically sign a new contract (legally binding!). Signing in the end means to send a request containing the hash of the document to an API. The API will respond with an CM/S Object containing signature, certificate etc that the client will embedded in the contract document (typical PDF). We want the user to authorize the signing request using their bank as IDP/AS.. Therefore the client sends the OAuth authorization request to the AS. The actual signing request needs to be bound to client, user AND hash (document) in order to prevent fraud. Regulation (eIDAS) requires to always demonstrate the sole control of the user over the whole process. The AS therefore binds (scopes) the access token to exactly this single document/signing request. If the client wants the user to sign another document, it needs to got through the whole process again. One could think about a general signing permission represented by a refresh token, but not in the high assurance level cases I‘m looking into. Hope that helps, Torsten. smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Dynamic Scopes
On 6/22/18 4:31 PM, Torsten Lodderstedt wrote:
Hi George,
Is the goal to bind an access token to a particular transaction? If this is the case, would it not
be better to either extend the refresh_token flow or may better yet, create a new grant_type that
takes the refresh_token and additional "binding" parameters and then have that return the
"bound" access token to be used for the transaction.
What would be the scope of such a refresh token?
I would think that the scope issued to the refresh_token could represent
the category or class of authorizations the refresh_token should be able
to perform. For example, the kind of transactions that can be bound to
access tokens. The scope issued into the access_token could be one of
the "parameterized" ones. But maybe I'm not fully understanding the use
case :)
On 6/20/18 5:58 PM, Brian Campbell wrote:
In my own personal and humble opinion, Torsten, what you describe as "(1) Parameter
is part of the scope value" is the most natural approach and works without needing
changes to, or going outside of, RFC6749 The OAuth 2.0 Authorization Framework. There may
be AS implementations that have made assumption about scope values being static (I know
of at least one!) but that's an implementation/feature issue, which can change, and not a
spec issue.
The OIDC "claims" parameter is already a bit of a hairy beast and I think using
it and the ID Token to convey more dynamic access/authorization is blurring the line
between authorization and authentication a bit much. Also, as others have pointed out,
OIDC isn't always in play - particularly for regular old authorization cases.
An additional query parameter might be simple for a one-off case but it's
nonstandard and not very repeatable.
On Mon, Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt
wrote:
Hi all,
I have been working lately on use cases where OAuth is used to authorize
transactions in the financial sector and electronic signing. What I learned is
there is always the need to pass resource ids (e.g. account numbers) or
transaction-specific values (e.g. amount or hash to be signed) to the OAuth
authorization process to further qualify the scope of the requested access
token.
It is obvious a static scope value, such as „payment“or „sign“, won’t do the
job. For example in case of electronic signing, one must bind the
authorization/access token to a particular document, typically represented by
its hash.
I would like to get your feedback on what you consider a good practice to cope
with that challenge. As a starting point for a discussion, I have assembled a
list of patterns I have seen in the wild (feel free to extend).
(1) Parameter is part of the scope value, e.g. „sign:“ or
"payments:" - I think this is an obvious way to represent such
parameters in OAuth, as it extends the scope parameter, which is intended to represent the requested
scope of an access token. I used this pattern in the OAuth SCA mode in Berlin Group's PSD API.
(2) One could also use additional query parameter to add further details re the
requested authorization, e.g.
GET /authorize?
.
&scope=sign
.
&hash_to_be_signed=
It seems to be robust (easier to implement?) but means the scope only
represents the static part of the action. The AS needs to look into a further
parameter to fully understand the requested authorization.
(3) Open Banking UK utilizes the (OpenID Connect) „claims“ parameter to carry
additional data.
Example:
"claims": {
"id_token": {
"acr": {
"essential": true,
"value": "..."
},
"hash_to_be_signed": {
"essential": true,
"value": ""
}
},
"userinfo": {
"hash_to_be_signed": {
"essential": true,
"value": ""
}
}
}
I‘m looking forward for your feedback. Please also indicated whether you think
we should flush out a BCP on that topic.
kind regards,
Torsten.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
material for the sole use of the intended recipient(s). Any review, use,
distribution or disclosure by others is strictly prohibited.. If you have
received this communication in error, please notify the sender immediately by
e-mail and delete the message and any file attachments from your computer.
Thank you.
___
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
Re: [OAUTH-WG] Dynamic Scopes
Hi George,
> Am 22.06.2018 um 19:51 schrieb George Fletcher :
>
> I like the concept of parameterized scopes but I'm not sure they should be
> used for per-transaction use cases. It seems like the use cases presented are
> about operating on parameters specific to the transaction. Why are these part
> of the authorization flow?
The access token is good for a certain transaction only. In case of a
electronic signature, the access token is bound to a certain document or a set
of documents.
>
> Is the goal to bind an access token to a particular transaction? If this is
> the case, would it not be better to either extend the refresh_token flow or
> may better yet, create a new grant_type that takes the refresh_token and
> additional "binding" parameters and then have that return the "bound" access
> token to be used for the transaction.
What would be the scope of such a refresh token?
>
> Maybe this is similar to what Nat is describing with the staging API?
The staging API represents the data of a certain transaction in a resource,
which allows to parametrize the scope just with the identifier of that
resource. So the transaction data can be transmitted in a robust fashion.
best regards,
Torsten.
>
> Thanks,
> George
>
> On 6/20/18 5:58 PM, Brian Campbell wrote:
>> In my own personal and humble opinion, Torsten, what you describe as "(1)
>> Parameter is part of the scope value" is the most natural approach and works
>> without needing changes to, or going outside of, RFC6749 The OAuth 2.0
>> Authorization Framework. There may be AS implementations that have made
>> assumption about scope values being static (I know of at least one!) but
>> that's an implementation/feature issue, which can change, and not a spec
>> issue.
>>
>> The OIDC "claims" parameter is already a bit of a hairy beast and I think
>> using it and the ID Token to convey more dynamic access/authorization is
>> blurring the line between authorization and authentication a bit much. Also,
>> as others have pointed out, OIDC isn't always in play - particularly for
>> regular old authorization cases.
>>
>> An additional query parameter might be simple for a one-off case but it's
>> nonstandard and not very repeatable.
>>
>>
>> On Mon, Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt
>> wrote:
>> Hi all,
>>
>> I have been working lately on use cases where OAuth is used to authorize
>> transactions in the financial sector and electronic signing. What I learned
>> is there is always the need to pass resource ids (e.g. account numbers) or
>> transaction-specific values (e.g. amount or hash to be signed) to the OAuth
>> authorization process to further qualify the scope of the requested access
>> token.
>>
>> It is obvious a static scope value, such as „payment“or „sign“, won’t do the
>> job. For example in case of electronic signing, one must bind the
>> authorization/access token to a particular document, typically represented
>> by its hash.
>>
>> I would like to get your feedback on what you consider a good practice to
>> cope with that challenge. As a starting point for a discussion, I have
>> assembled a list of patterns I have seen in the wild (feel free to extend).
>>
>> (1) Parameter is part of the scope value, e.g. „sign:“ or
>> "payments:" - I think this is an obvious way to
>> represent such parameters in OAuth, as it extends the scope parameter, which
>> is intended to represent the requested scope of an access token. I used this
>> pattern in the OAuth SCA mode in Berlin Group's PSD API.
>>
>> (2) One could also use additional query parameter to add further details re
>> the requested authorization, e.g.
>>
>> GET /authorize?
>> .
>> &scope=sign
>> .
>> &hash_to_be_signed=
>>
>> It seems to be robust (easier to implement?) but means the scope only
>> represents the static part of the action. The AS needs to look into a
>> further parameter to fully understand the requested authorization.
>>
>> (3) Open Banking UK utilizes the (OpenID Connect) „claims“ parameter to
>> carry additional data.
>>
>> Example:
>>
>> "claims": {
>> "id_token": {
>> "acr": {
>> "essential": true,
>> "value": "..."
>> },
>> "hash_to_be_signed": {
>> "essential": true,
>> "value": ""
>> }
>> },
>> "userinfo": {
>> "hash_to_be_signed": {
>> "essential": true,
>> "value": ""
>> }
>> }
>> }
>>
>> I‘m looking forward for your feedback. Please also indicated whether you
>> think we should flush out a BCP on that topic.
>>
>> kind regards,
>> Torsten.
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
>> material for the sole use of the intended recipient(s). Any review
Re: [OAUTH-WG] Dynamic Scopes
I like the concept of parameterized scopes but I'm not sure they should
be used for per-transaction use cases. It seems like the use cases
presented are about operating on parameters specific to the transaction.
Why are these part of the authorization flow?
Is the goal to bind an access token to a particular transaction? If this
is the case, would it not be better to either extend the refresh_token
flow or may better yet, create a new grant_type that takes the
refresh_token and additional "binding" parameters and then have that
return the "bound" access token to be used for the transaction.
Maybe this is similar to what Nat is describing with the staging API?
Thanks,
George
On 6/20/18 5:58 PM, Brian Campbell wrote:
In my own personal and humble opinion, Torsten, what you describe as
"(1) Parameter is part of the scope value" is the most natural
approach and works without needing changes to, or going outside of,
RFC6749 The OAuth 2.0 Authorization Framework. There may be AS
implementations that have made assumption about scope values being
static (I know of at least one!) but that's an implementation/feature
issue, which can change, and not a spec issue.
The OIDC "claims" parameter is already a bit of a hairy beast and I
think using it and the ID Token to convey more dynamic
access/authorization is blurring the line between authorization and
authentication a bit much. Also, as others have pointed out, OIDC
isn't always in play - particularly for regular old authorization cases.
An additional query parameter might be simple for a one-off case but
it's nonstandard and not very repeatable.
On Mon, Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt
mailto:tors...@lodderstedt.net>> wrote:
Hi all,
I have been working lately on use cases where OAuth is used to
authorize transactions in the financial sector and electronic
signing. What I learned is there is always the need to pass
resource ids (e.g. account numbers) or transaction-specific values
(e.g. amount or hash to be signed) to the OAuth authorization
process to further qualify the scope of the requested access token.
It is obvious a static scope value, such as „payment“or „sign“,
won’t do the job. For example in case of electronic signing, one
must bind the authorization/access token to a particular document,
typically represented by its hash.
I would like to get your feedback on what you consider a good
practice to cope with that challenge. As a starting point for a
discussion, I have assembled a list of patterns I have seen in the
wild (feel free to extend).
(1) Parameter is part of the scope value, e.g.
„sign:“ or "payments:" - I
think this is an obvious way to represent such parameters in
OAuth, as it extends the scope parameter, which is intended to
represent the requested scope of an access token. I used this
pattern in the OAuth SCA mode in Berlin Group's PSD API.
(2) One could also use additional query parameter to add further
details re the requested authorization, e.g.
GET /authorize?
.
&scope=sign
.
&hash_to_be_signed=
It seems to be robust (easier to implement?) but means the scope
only represents the static part of the action. The AS needs to
look into a further parameter to fully understand the requested
authorization.
(3) Open Banking UK utilizes the (OpenID Connect) „claims“
parameter to carry additional data.
Example:
"claims": {
"id_token": {
"acr": {
"essential": true,
"value": "..."
},
"hash_to_be_signed": {
"essential": true,
"value": ""
}
},
"userinfo": {
"hash_to_be_signed": {
"essential": true,
"value": ""
}
}
}
I‘m looking forward for your feedback. Please also indicated
whether you think we should flush out a BCP on that topic.
kind regards,
Torsten.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
/CONFIDENTIALITY NOTICE: This email may contain confidential and
privileged material for the sole use of the intended recipient(s). Any
review, use, distribution or disclosure by others is strictly
prohibited.. If you have received this communication in error, please
notify the sender immediately by e-mail and delete the message and any
file attachments from your computer. Thank you./
___
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
Re: [OAUTH-WG] Dynamic Scopes
Hi Torsten, Re: using request object Carrying the scope parameter in the request object solves the integrity issue. However, it does not solve the confidentiality issue unless you also encrypt it, and encryption is not so easy. Re: 2 extra roundtrips You can actually cut the extra roundtrips to one. In fact, you probably want to have the staging object to be signed to have it work as an evidence when something goes wrong, so you could rely on that for the client authentication purpose and that will be more efficient, IMHO. Yes, that will become essentially the request_uri model. Cheers, Nat 2018年6月22日金曜日、Torsten Lodderstedtさんは書きました: > Hi Nat, > > > Am 21.06.2018 um 10:35 schrieb Nat Sakimura : > > > > It depends on the use case but if you are talking about payment etc., > putting the transaction details in the scope and sending it over the > regular RFC6749 redirect to the authorization server is inherently a bad > idea, as it is not protected. > > Good point. One could carry the scope parameter as part of a signed > request object to cope with that issue. What do you think about that? > > > > > My preference by far is to set up a staging endpoint and push the > transaction intent into there. Then, do the authorization on that staged > transaction. Once that's done. I am OK with putting the reference to the > staged transaction in the scope parameter. > > > > The beauty of the "staging" strategy is that: > > > > 1) You can push pretty big payload to the staging endpoint as it is a > server to server thing; > > 2) You can do the "auth" and then later "capture" after shipping the > product strategy using the access token the client has obtained; > > 3) The content of the transaction is not exposed via URL nor referrers. > > I agree. That’s really powerful. But one should also admit the client > needs to prepare and send two more requests. In OB UK the client first > obtains an access token using the client credentials grant and then creates > the payment/account information resource. > > best regards, > Torsten. > > > > > Best, > > > > Nat > > > > > > > > On Thu, Jun 21, 2018 at 6:59 AM Brian Campbell 40pingidentity@dmarc.ietf.org> wrote: > > In my own personal and humble opinion, Torsten, what you describe as > "(1) Parameter is part of the scope value" is the most natural approach and > works without needing changes to, or going outside of, RFC6749 The OAuth > 2.0 Authorization Framework. There may be AS implementations that have made > assumption about scope values being static (I know of at least one!) but > that's an implementation/feature issue, which can change, and not a spec > issue. > > > > The OIDC "claims" parameter is already a bit of a hairy beast and I > think using it and the ID Token to convey more dynamic access/authorization > is blurring the line between authorization and authentication a bit much. > Also, as others have pointed out, OIDC isn't always in play - particularly > for regular old authorization cases. > > > > An additional query parameter might be simple for a one-off case but > it's nonstandard and not very repeatable. > > > > > > On Mon, Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt < > tors...@lodderstedt.net> wrote: > > Hi all, > > > > I have been working lately on use cases where OAuth is used to authorize > transactions in the financial sector and electronic signing. What I learned > is there is always the need to pass resource ids (e.g. account numbers) or > transaction-specific values (e.g. amount or hash to be signed) to the OAuth > authorization process to further qualify the scope of the requested access > token. > > > > It is obvious a static scope value, such as „payment“or „sign“, won’t do > the job. For example in case of electronic signing, one must bind the > authorization/access token to a particular document, typically represented > by its hash. > > > > I would like to get your feedback on what you consider a good practice > to cope with that challenge. As a starting point for a discussion, I have > assembled a list of patterns I have seen in the wild (feel free to extend). > > > > (1) Parameter is part of the scope value, e.g. > „sign:“ or "payments:" - I think > this is an obvious way to represent such parameters in OAuth, as it extends > the scope parameter, which is intended to represent the requested scope of > an access token. I used this pattern in the OAuth SCA mode in Berlin > Group's PSD API. > > > > (2) One could also use additional query parameter to add further details > re the requested authorization, e.g. > > > > GET /authorize? > > . > > &scope=sign > > . > > > > &hash_to_be_signed= > > > > It seems to be robust (easier to implement?) but means the scope only > represents the static part of the action. The AS needs to look into a > further parameter to fully understand the requested authorization. > > > > (3) Open Banking UK utilizes the (OpenID Connect) „claims“ parameter to > carry additional data. > > > > Example: > > > >
Re: [OAUTH-WG] Dynamic Scopes
Hi Nat,
> Am 21.06.2018 um 10:35 schrieb Nat Sakimura :
>
> It depends on the use case but if you are talking about payment etc., putting
> the transaction details in the scope and sending it over the regular RFC6749
> redirect to the authorization server is inherently a bad idea, as it is not
> protected.
Good point. One could carry the scope parameter as part of a signed request
object to cope with that issue. What do you think about that?
>
> My preference by far is to set up a staging endpoint and push the transaction
> intent into there. Then, do the authorization on that staged transaction.
> Once that's done. I am OK with putting the reference to the staged
> transaction in the scope parameter.
>
> The beauty of the "staging" strategy is that:
>
> 1) You can push pretty big payload to the staging endpoint as it is a server
> to server thing;
> 2) You can do the "auth" and then later "capture" after shipping the product
> strategy using the access token the client has obtained;
> 3) The content of the transaction is not exposed via URL nor referrers.
I agree. That’s really powerful. But one should also admit the client needs to
prepare and send two more requests. In OB UK the client first obtains an access
token using the client credentials grant and then creates the payment/account
information resource.
best regards,
Torsten.
>
> Best,
>
> Nat
>
>
>
> On Thu, Jun 21, 2018 at 6:59 AM Brian Campbell
> wrote:
> In my own personal and humble opinion, Torsten, what you describe as "(1)
> Parameter is part of the scope value" is the most natural approach and works
> without needing changes to, or going outside of, RFC6749 The OAuth 2.0
> Authorization Framework. There may be AS implementations that have made
> assumption about scope values being static (I know of at least one!) but
> that's an implementation/feature issue, which can change, and not a spec
> issue.
>
> The OIDC "claims" parameter is already a bit of a hairy beast and I think
> using it and the ID Token to convey more dynamic access/authorization is
> blurring the line between authorization and authentication a bit much. Also,
> as others have pointed out, OIDC isn't always in play - particularly for
> regular old authorization cases.
>
> An additional query parameter might be simple for a one-off case but it's
> nonstandard and not very repeatable.
>
>
> On Mon, Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt
> wrote:
> Hi all,
>
> I have been working lately on use cases where OAuth is used to authorize
> transactions in the financial sector and electronic signing. What I learned
> is there is always the need to pass resource ids (e.g. account numbers) or
> transaction-specific values (e.g. amount or hash to be signed) to the OAuth
> authorization process to further qualify the scope of the requested access
> token.
>
> It is obvious a static scope value, such as „payment“or „sign“, won’t do the
> job. For example in case of electronic signing, one must bind the
> authorization/access token to a particular document, typically represented by
> its hash.
>
> I would like to get your feedback on what you consider a good practice to
> cope with that challenge. As a starting point for a discussion, I have
> assembled a list of patterns I have seen in the wild (feel free to extend).
>
> (1) Parameter is part of the scope value, e.g. „sign:“ or
> "payments:" - I think this is an obvious way to
> represent such parameters in OAuth, as it extends the scope parameter, which
> is intended to represent the requested scope of an access token. I used this
> pattern in the OAuth SCA mode in Berlin Group's PSD API.
>
> (2) One could also use additional query parameter to add further details re
> the requested authorization, e.g.
>
> GET /authorize?
> .
> &scope=sign
> .
>
> &hash_to_be_signed=
>
> It seems to be robust (easier to implement?) but means the scope only
> represents the static part of the action. The AS needs to look into a further
> parameter to fully understand the requested authorization.
>
> (3) Open Banking UK utilizes the (OpenID Connect) „claims“ parameter to carry
> additional data.
>
> Example:
>
> "claims": {
> "id_token": {
> "acr": {
> "essential": true,
> "value": "..."
> },
> "hash_to_be_signed": {
> "essential": true,
> "value": ""
> }
> },
> "userinfo": {
> "hash_to_be_signed": {
> "essential": true,
> "value": ""
> }
> }
> }
>
> I‘m looking forward for your feedback. Please also indicated whether you
> think we should flush out a BCP on that topic.
>
> kind regards,
> Torsten.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and priv
Re: [OAUTH-WG] Dynamic Scopes
It depends on the use case but if you are talking about payment etc.,
putting the transaction details in the scope and sending it over the
regular RFC6749 redirect to the authorization server is inherently a bad
idea, as it is not protected.
My preference by far is to set up a staging endpoint and push the
transaction intent into there. Then, do the authorization on that staged
transaction. Once that's done. I am OK with putting the reference to the
staged transaction in the scope parameter.
The beauty of the "staging" strategy is that:
1) You can push pretty big payload to the staging endpoint as it is a
server to server thing;
2) You can do the "auth" and then later "capture" after shipping the
product strategy using the access token the client has obtained;
3) The content of the transaction is not exposed via URL nor referrers.
Best,
Nat
On Thu, Jun 21, 2018 at 6:59 AM Brian Campbell wrote:
> In my own personal and humble opinion, Torsten, what you describe as "(1)
> Parameter is part of the scope value" is the most natural approach and
> works without needing changes to, or going outside of, RFC6749 The OAuth
> 2.0 Authorization Framework. There may be AS implementations that have made
> assumption about scope values being static (I know of at least one!) but
> that's an implementation/feature issue, which can change, and not a spec
> issue.
>
> The OIDC "claims" parameter is already a bit of a hairy beast and I think
> using it and the ID Token to convey more dynamic access/authorization is
> blurring the line between authorization and authentication a bit much.
> Also, as others have pointed out, OIDC isn't always in play - particularly
> for regular old authorization cases.
>
> An additional query parameter might be simple for a one-off case but it's
> nonstandard and not very repeatable.
>
>
> On Mon, Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> Hi all,
>>
>> I have been working lately on use cases where OAuth is used to authorize
>> transactions in the financial sector and electronic signing. What I learned
>> is there is always the need to pass resource ids (e.g. account numbers) or
>> transaction-specific values (e.g. amount or hash to be signed) to the OAuth
>> authorization process to further qualify the scope of the requested access
>> token.
>>
>> It is obvious a static scope value, such as „payment“or „sign“, won’t do
>> the job. For example in case of electronic signing, one must bind the
>> authorization/access token to a particular document, typically represented
>> by its hash.
>>
>> I would like to get your feedback on what you consider a good practice to
>> cope with that challenge. As a starting point for a discussion, I have
>> assembled a list of patterns I have seen in the wild (feel free to extend).
>>
>> (1) Parameter is part of the scope value, e.g. „sign:“
>> or "payments:" - I think this is an obvious way to
>> represent such parameters in OAuth, as it extends the scope parameter,
>> which is intended to represent the requested scope of an access token. I
>> used this pattern in the OAuth SCA mode in Berlin Group's PSD API.
>>
>> (2) One could also use additional query parameter to add further details
>> re the requested authorization, e.g.
>>
>> GET /authorize?
>>
> .
>> &scope=sign
>> .
>
>
>> &hash_to_be_signed=
>>
>> It seems to be robust (easier to implement?) but means the scope only
>> represents the static part of the action. The AS needs to look into a
>> further parameter to fully understand the requested authorization.
>>
>> (3) Open Banking UK utilizes the (OpenID Connect) „claims“ parameter to
>> carry additional data.
>>
>> Example:
>>
>> "claims": {
>> "id_token": {
>> "acr": {
>> "essential": true,
>> "value": "..."
>> },
>> "hash_to_be_signed": {
>> "essential": true,
>> "value": ""
>> }
>> },
>> "userinfo": {
>> "hash_to_be_signed": {
>> "essential": true,
>> "value": ""
>> }
>> }
>> }
>>
>> I‘m looking forward for your feedback. Please also indicated whether you
>> think we should flush out a BCP on that topic.
>>
>> kind regards,
>> Torsten.
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited...
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
Nat Sakimura
Chairman of the Board, OpenID Foun
Re: [OAUTH-WG] Dynamic Scopes
In my own personal and humble opinion, Torsten, what you describe as "(1)
Parameter is part of the scope value" is the most natural approach and
works without needing changes to, or going outside of, RFC6749 The OAuth
2.0 Authorization Framework. There may be AS implementations that have made
assumption about scope values being static (I know of at least one!) but
that's an implementation/feature issue, which can change, and not a spec
issue.
The OIDC "claims" parameter is already a bit of a hairy beast and I think
using it and the ID Token to convey more dynamic access/authorization is
blurring the line between authorization and authentication a bit much.
Also, as others have pointed out, OIDC isn't always in play - particularly
for regular old authorization cases.
An additional query parameter might be simple for a one-off case but it's
nonstandard and not very repeatable.
On Mon, Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> Hi all,
>
> I have been working lately on use cases where OAuth is used to authorize
> transactions in the financial sector and electronic signing. What I learned
> is there is always the need to pass resource ids (e.g. account numbers) or
> transaction-specific values (e.g. amount or hash to be signed) to the OAuth
> authorization process to further qualify the scope of the requested access
> token.
>
> It is obvious a static scope value, such as „payment“or „sign“, won’t do
> the job. For example in case of electronic signing, one must bind the
> authorization/access token to a particular document, typically represented
> by its hash.
>
> I would like to get your feedback on what you consider a good practice to
> cope with that challenge. As a starting point for a discussion, I have
> assembled a list of patterns I have seen in the wild (feel free to extend).
>
> (1) Parameter is part of the scope value, e.g. „sign:“
> or "payments:" - I think this is an obvious way to
> represent such parameters in OAuth, as it extends the scope parameter,
> which is intended to represent the requested scope of an access token. I
> used this pattern in the OAuth SCA mode in Berlin Group's PSD API.
>
> (2) One could also use additional query parameter to add further details
> re the requested authorization, e.g.
>
> GET /authorize?
>
> &scope=sign
>
> &hash_to_be_signed=
>
> It seems to be robust (easier to implement?) but means the scope only
> represents the static part of the action. The AS needs to look into a
> further parameter to fully understand the requested authorization.
>
> (3) Open Banking UK utilizes the (OpenID Connect) „claims“ parameter to
> carry additional data.
>
> Example:
>
> "claims": {
> "id_token": {
> "acr": {
> "essential": true,
> "value": "..."
> },
> "hash_to_be_signed": {
> "essential": true,
> "value": ""
> }
> },
> "userinfo": {
> "hash_to_be_signed": {
> "essential": true,
> "value": ""
> }
> }
> }
>
> I‘m looking forward for your feedback. Please also indicated whether you
> think we should flush out a BCP on that topic.
>
> kind regards,
> Torsten.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
--
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
material for the sole use of the intended recipient(s). Any review, use,
distribution or disclosure by others is strictly prohibited. If you have
received this communication in error, please notify the sender immediately
by e-mail and delete the message and any file attachments from your
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Dynamic Scopes
Hi Jacob, thanks for your thoughts on dynamic scopes. > Am 19.06.2018 um 08:16 schrieb Jacob Ideskog : > > For OpenID I still think the signed claims parameters make a more flexible > approach, but OpenID isn't always in play. Why do you think it is more flexible? kind regards, Torsten. smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Dynamic Scopes
This borderlines another problem we've been adressing which is when a client needs to pass on the request to an asyncronous queue. In that case the client can request the AS to "downscope" it's token, and include a signature of the request in the token. (simplified). The dynamic scope approach would help in this case also, i.e. have a dynamic scope "sign:" which lets the client downscope it by adding the actual signature/hash of the request to the token endpoint in a refresh (sign:). Since we then consider sign: to be the downscoped version of sign:, thus allowing the AS to issue this AT. Also, one-off scopes are useful in services like pay per view etc, where you can purchase say a single movie, game etc. Then the dynamic scope can be decided to be issued by the AS rathern than specifically asked for by the client. Example client asks for games: and gets games:world-cup-2018-06-15 etc. So, the scope approach seems like a more general approach for both the authorize endpoint as well as the token endpoint. With that said, it will probably make it hard to narrow down dynamic scopes to single particular usecase. It would mean that 1. If a dynamic scope is requested on the Authorize endpoint it's a consentable request that the user needs to sign 2. If a dynamic scope is requested on the Token endpoint, the AS determines what the end result might be. Seems a bit vague perhaps. For OpenID I still think the signed claims parameters make a more flexible approach, but OpenID isn't always in play. Just my 5-cents /Jacob Ideskog Curity mån 18 juni 2018 kl 21:00 skrev David Waite : > One of the reasons I hear for people wanting parameterized scopes is to > deal with transactions. I’d love to hear thoughts from the group on if/how > OAuth should be used to authorize a transaction, vs authorize access to > information/actions for a period of time. This approach for instance sounds > like it is trying to scope down access to a single resource representing a > transaction to be performed? > > I also hear people wanting dynamic scopes to support a finer-grained > access control, for instance not ‘allow moderation of chat rooms’ but > rather the list of *specific* rooms. There is sometimes a case to be made > that this would be better served as local state in the resource, or as the > result of an API call, but there is value in some use cases to represent > this as a finer-grained consent to the user. > > I’ve seen parameterized scopes take the form of colon-deliminated > name:param, as a function name(param), or as a URL > https://nameurl?param=value. The latter is recommended sometimes in > specs like opened connect as a way to prevent conflicting vendor extensions. > > In terms of requesting a parameterized scope - I prefer overloading scope > (or perhaps claims when using connect) vs adding a new authorization > request parameter - for one, use of authorization request parameters limits > your grant type options unless you also define them as token request > parameters for the other types. Second, the consent/business logic for > determining which scopes a client get should already be a customization > point for a reusable AS. > > -DW > > > On Jun 18, 2018, at 9:34 AM, Torsten Lodderstedt < > tors...@lodderstedt.net> wrote: > > > > Hi all, > > > > I have been working lately on use cases where OAuth is used to authorize > transactions in the financial sector and electronic signing. What I learned > is there is always the need to pass resource ids (e.g. account numbers) or > transaction-specific values (e.g. amount or hash to be signed) to the OAuth > authorization process to further qualify the scope of the requested access > token. > > > > It is obvious a static scope value, such as „payment“or „sign“, won’t do > the job. For example in case of electronic signing, one must bind the > authorization/access token to a particular document, typically represented > by its hash. > > > > I would like to get your feedback on what you consider a good practice > to cope with that challenge. As a starting point for a discussion, I have > assembled a list of patterns I have seen in the wild (feel free to extend). > > > > (1) Parameter is part of the scope value, e.g. > „sign:“ or "payments:" - I think > this is an obvious way to represent such parameters in OAuth, as it extends > the scope parameter, which is intended to represent the requested scope of > an access token. I used this pattern in the OAuth SCA mode in Berlin > Group's PSD API. > > > > (2) One could also use additional query parameter to add further details > re the requested authorization, e.g. > > > > GET /authorize? > > > > &scope=sign > > > > &hash_to_be_signed= > > > > It seems to be robust (easier to implement?) but means the scope only > represents the static part of the action. The AS needs to look into a > further parameter to fully understand the requested authorization. > > > > (3) Open Banking UK utilizes the (OpenID Connect) „claims“
Re: [OAUTH-WG] Dynamic Scopes
One of the reasons I hear for people wanting parameterized scopes is to deal
with transactions. I’d love to hear thoughts from the group on if/how OAuth
should be used to authorize a transaction, vs authorize access to
information/actions for a period of time. This approach for instance sounds
like it is trying to scope down access to a single resource representing a
transaction to be performed?
I also hear people wanting dynamic scopes to support a finer-grained access
control, for instance not ‘allow moderation of chat rooms’ but rather the list
of *specific* rooms. There is sometimes a case to be made that this would be
better served as local state in the resource, or as the result of an API call,
but there is value in some use cases to represent this as a finer-grained
consent to the user.
I’ve seen parameterized scopes take the form of colon-deliminated name:param,
as a function name(param), or as a URL https://nameurl?param=value. The latter
is recommended sometimes in specs like opened connect as a way to prevent
conflicting vendor extensions.
In terms of requesting a parameterized scope - I prefer overloading scope (or
perhaps claims when using connect) vs adding a new authorization request
parameter - for one, use of authorization request parameters limits your grant
type options unless you also define them as token request parameters for the
other types. Second, the consent/business logic for determining which scopes a
client get should already be a customization point for a reusable AS.
-DW
> On Jun 18, 2018, at 9:34 AM, Torsten Lodderstedt
> wrote:
>
> Hi all,
>
> I have been working lately on use cases where OAuth is used to authorize
> transactions in the financial sector and electronic signing. What I learned
> is there is always the need to pass resource ids (e.g. account numbers) or
> transaction-specific values (e.g. amount or hash to be signed) to the OAuth
> authorization process to further qualify the scope of the requested access
> token.
>
> It is obvious a static scope value, such as „payment“or „sign“, won’t do the
> job. For example in case of electronic signing, one must bind the
> authorization/access token to a particular document, typically represented by
> its hash.
>
> I would like to get your feedback on what you consider a good practice to
> cope with that challenge. As a starting point for a discussion, I have
> assembled a list of patterns I have seen in the wild (feel free to extend).
>
> (1) Parameter is part of the scope value, e.g. „sign:“ or
> "payments:" - I think this is an obvious way to
> represent such parameters in OAuth, as it extends the scope parameter, which
> is intended to represent the requested scope of an access token. I used this
> pattern in the OAuth SCA mode in Berlin Group's PSD API.
>
> (2) One could also use additional query parameter to add further details re
> the requested authorization, e.g.
>
> GET /authorize?
>
> &scope=sign
>
> &hash_to_be_signed=
>
> It seems to be robust (easier to implement?) but means the scope only
> represents the static part of the action. The AS needs to look into a further
> parameter to fully understand the requested authorization.
>
> (3) Open Banking UK utilizes the (OpenID Connect) „claims“ parameter to carry
> additional data.
>
> Example:
>
> "claims": {
>"id_token": {
>"acr": {
>"essential": true,
>"value": "..."
> },
>"hash_to_be_signed": {
>"essential": true,
>"value": ""
>}
>},
>"userinfo": {
>"hash_to_be_signed": {
>"essential": true,
>"value": ""
>}
>}
> }
>
> I‘m looking forward for your feedback. Please also indicated whether you
> think we should flush out a BCP on that topic.
>
> 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
