Re: [OAUTH-WG] Dynamic Scopes

2018-06-21 Thread 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.

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

[OAUTH-WG] Standardizing Attestation Tokens

2018-06-21 Thread Hannes Tschofenig 
Hi all,

I would like to make you aware of work that will be discussed on attestation on 
the EAT mailing list. Here is the link to the list:
https://www.ietf.org/mailman/listinfo/eat

Here is a document describing the idea:
https://tools.ietf.org/html/draft-mandyam-eat-00

The work is relevant for IoT and non-IoT devices.

Laurence and I are planning to organize a Bar BOF at the Montreal IETF meeting 
to entertain the idea.

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Standardizing Attestation Tokens

2018-06-21 Thread Eliot Lear 
Hi Hannes,

The draft is interesting, but it looks a bit like NEA.  How would this
vary, apart from the CoAP part and a different registry?  Seems to me
the real magic is how the device is interrogated such that the consumer
of this information has confidence as to its validity.  The protocol
bits are the easy part.  If people have some understanding of that magic
and are willing to share, then this work becomes considerably more
interesting.

Eliot


On 21.06.18 17:11, Hannes Tschofenig wrote:
>
> Hi all,
>
>  
>
> I would like to make you aware of work that will be discussed on
> attestation on the EAT mailing list. Here is the link to the list:
>
> https://www.ietf.org/mailman/listinfo/eat
>
>  
>
> Here is a document describing the idea:
>
> https://tools.ietf.org/html/draft-mandyam-eat-00
>
>  
>
> The work is relevant for IoT and non-IoT devices.
>
>  
>
> Laurence and I are planning to organize a Bar BOF at the Montreal IETF
> meeting to entertain the idea.
>
>  
>
> Ciao
>
> Hannes
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose
> the contents to any other person, use it for any purpose, or store or
> copy the information in any medium. Thank you.
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Standardizing Attestation Tokens

2018-06-21 Thread Hannes Tschofenig 
That’s a good question, Eliot. Let me put something together for the IETF 
meeting

From: Eliot Lear [mailto:l...@cisco.com]
Sent: 21 June 2018 20:17
To: Hannes Tschofenig; oauth@ietf.org
Cc: Laurence Lundblade; e...@ietf.org
Subject: Re: [OAUTH-WG] Standardizing Attestation Tokens


Hi Hannes,

The draft is interesting, but it looks a bit like NEA.  How would this vary, 
apart from the CoAP part and a different registry?  Seems to me the real magic 
is how the device is interrogated such that the consumer of this information 
has confidence as to its validity.  The protocol bits are the easy part.  If 
people have some understanding of that magic and are willing to share, then 
this work becomes considerably more interesting.

Eliot

On 21.06.18 17:11, Hannes Tschofenig wrote:
Hi all,

I would like to make you aware of work that will be discussed on attestation on 
the EAT mailing list. Here is the link to the list:
https://www.ietf.org/mailman/listinfo/eat

Here is a document describing the idea:
https://tools.ietf.org/html/draft-mandyam-eat-00

The work is relevant for IoT and non-IoT devices.

Laurence and I are planning to organize a Bar BOF at the Montreal IETF meeting 
to entertain the idea.

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.



___

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Standardizing Attestation Tokens

2018-06-21 Thread Eliot Lear 
By the way, a lot *has* changed.  If we can use the TEE to get signed
information out... if *it* is the attester, that's a pretty big
benefit.  That just leaves the protocol gorp.  But one needs to know
that there is a TEE.


On 21.06.18 22:04, Hannes Tschofenig wrote:
>
> That’s a good question, Eliot. Let me put something together for the
> IETF meeting
>
>  
>
> *From:*Eliot Lear [mailto:l...@cisco.com]
> *Sent:* 21 June 2018 20:17
> *To:* Hannes Tschofenig; oauth@ietf.org
> *Cc:* Laurence Lundblade; e...@ietf.org
> *Subject:* Re: [OAUTH-WG] Standardizing Attestation Tokens
>
>  
>
> Hi Hannes,
>
> The draft is interesting, but it looks a bit like NEA.  How would this
> vary, apart from the CoAP part and a different registry?  Seems to me
> the real magic is how the device is interrogated such that the
> consumer of this information has confidence as to its validity.  The
> protocol bits are the easy part.  If people have some understanding of
> that magic and are willing to share, then this work becomes
> considerably more interesting.
>
> Eliot
>
>  
>
> On 21.06.18 17:11, Hannes Tschofenig wrote:
>
> Hi all,
>
>  
>
> I would like to make you aware of work that will be discussed on
> attestation on the EAT mailing list. Here is the link to the list:
>
> https://www.ietf.org/mailman/listinfo/eat
>
>  
>
> Here is a document describing the idea:
>
> https://tools.ietf.org/html/draft-mandyam-eat-00
>
>  
>
> The work is relevant for IoT and non-IoT devices.
>
>  
>
> Laurence and I are planning to organize a Bar BOF at the Montreal
> IETF meeting to entertain the idea.
>
>  
>
> Ciao
>
> Hannes
>
> IMPORTANT NOTICE: The contents of this email and any attachments
> are confidential and may also be privileged. If you are not the
> intended recipient, please notify the sender immediately and do
> not disclose the contents to any other person, use it for any
> purpose, or store or copy the information in any medium. Thank you.
>
>
> ___
>
> OAuth mailing list
>
> OAuth@ietf.org 
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>  
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose
> the contents to any other person, use it for any purpose, or store or
> copy the information in any medium. Thank you. 



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Standardizing Attestation Tokens

2018-06-21 Thread Hannes Tschofenig 
I guess this is a piece of info we should have mentioned somewhere. Yes, the 
idea is to use a TEE for that purpose.
At least for Arm, TrustZone for v8-M even brings TEE capabilities to the 
low-end IoT devices and the first products are already on the market.

Ciao
Hannes

From: Eliot Lear [mailto:l...@cisco.com]
Sent: 22 June 2018 07:02
To: Hannes Tschofenig; oauth@ietf.org
Cc: Laurence Lundblade; e...@ietf.org
Subject: Re: [OAUTH-WG] Standardizing Attestation Tokens


By the way, a lot *has* changed.  If we can use the TEE to get signed 
information out... if *it* is the attester, that's a pretty big benefit.  That 
just leaves the protocol gorp.  But one needs to know that there is a TEE.

On 21.06.18 22:04, Hannes Tschofenig wrote:
That’s a good question, Eliot. Let me put something together for the IETF 
meeting

From: Eliot Lear [mailto:l...@cisco.com]
Sent: 21 June 2018 20:17
To: Hannes Tschofenig; oauth@ietf.org
Cc: Laurence Lundblade; e...@ietf.org
Subject: Re: [OAUTH-WG] Standardizing Attestation Tokens


Hi Hannes,

The draft is interesting, but it looks a bit like NEA.  How would this vary, 
apart from the CoAP part and a different registry?  Seems to me the real magic 
is how the device is interrogated such that the consumer of this information 
has confidence as to its validity.  The protocol bits are the easy part.  If 
people have some understanding of that magic and are willing to share, then 
this work becomes considerably more interesting.

Eliot

On 21.06.18 17:11, Hannes Tschofenig wrote:
Hi all,

I would like to make you aware of work that will be discussed on attestation on 
the EAT mailing list. Here is the link to the list:
https://www.ietf.org/mailman/listinfo/eat

Here is a document describing the idea:
https://tools.ietf.org/html/draft-mandyam-eat-00

The work is relevant for IoT and non-IoT devices.

Laurence and I are planning to organize a Bar BOF at the Montreal IETF meeting 
to entertain the idea.

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.




___

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth