> On May 8, 2019, at 1:37 AM, Emond Papegaaij wrote:
>
> On maandag 6 mei 2019 22:42:09 CEST David Waite wrote:
>> On May 6, 2019, at 1:42 PM, Emond Papegaaij
>
>> You could also trigger re-authorization with a user click, thus allowing
>> opening the AS in a new window or tab. Once back on
One case I have seen back in the AAD days was when a RS wants to authorize
calls from specific clients. In there a client can act both as confidential
and as public client, and in the case of public client the client_id can be
reused by any app really - hence just looking at the client_id in the
in
On 08/05/2019 11:57, Neil Madden wrote:
> Why does the RS need to know if the subject is a client vs a user? I suspect
> the answers to that question are about as problematic as the RS needing to
> know about the grant type.
I have the exact same question.
Could someone comment on that?
I cann
Maybe this is a dumb question, but why would an AS allow a client to
register it's own client_id rather than issuing the client a client_id
within the namespace of the AS?
Also, a client_id or sub should NEVER be treated as unique without the
context of the issuer. In that regard, the AS (as T
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
You are right. May I ask you to propose text (threat description, advice, ...)
to be included in the BCP?
> On 7. May 2019, at 13:23, Neil Madden wrote:
>
> The same issue applies to token introspection responses though.
>
>> On 7 May 2019, at 12:21, Torsten Lodderstedt wrote:
>>
>> Hi Neil
An AS (and also an OP) MUST ensure uniqueness of any id that may end up in a
“sub". OpenID Connect even states that explicitly. That way the recipient of
the data (token, assertion, introspection response, …) does not need to know
anything about account types.
Having the same sub value for a u
On Wed, May 8, 2019 at 9:38 AM Emond Papegaaij
wrote:
> In our case or AS might have to federate the authentication to some other
> AS,
> that would only work in an iframe. Therefore, I think we will go for the
> OIDC
> prompt=none in a hidden iframe. I'm not sure what to do if the AS reports
> t
Why does the RS need to know if the subject is a client vs a user? I suspect
the answers to that question are about as problematic as the RS needing to know
about the grant type.
I’m not a fan of the client_credentials grant, better off using a real service
account in most cases. Hopefully no n
This is an excellent security point.
I also imagine that in "federated" cases an RS could have its own
subject scheme / namespace, distinct from the one at the AS, including
for clients acting on their own behalf.
Vladimir
On 07/05/2019 11:37, Neil Madden wrote:
> I wasn’t at IIW so I may be mis
Hi Ben,
> I've forgotten the details of those two documents, but in the general case,
> if there's a WG document that is no longer actively being worked on (or is
> now believed to be a bad idea), the chairs can pretty easily get a new rev
> posted that has a "tombstone" notice, like "this docu
> On May 7, 2019, at 8:02 AM, John Bradley wrote:
>
> I believe that for a native app to use mtls via a chrome custom tab or Safari
> view controller you need to provision a certificate and private key to the
> system keystore. It is not something that can happen dynamically from the
> app
On 07/05/2019 11:48, Vittorio Bertocci wrote:
> name
> TBD given that sub_type is taken already
Meaning that it cannot be used in a AT as JWT?
What spec is that?
Thanks,
Vladimir
--
Vladimir Dzhuvinov
___
OAuth mailing list
OAuth@ietf.org
https://w
grant_type would be horrible for RS developers to deal with, just to
find out whether "sub" effectively == "client_id".
Why?
* RS developers will need to learn more OAuth stuff - there are better
ways to motivate people than that :)
* The OAuth grant types are unbounded. If at some point
Hi,
Thanks for your detailed reply. I've replied inline.
On maandag 6 mei 2019 22:42:09 CEST David Waite wrote:
> On May 6, 2019, at 1:42 PM, Emond Papegaaij
wrote:
> > For a browser-based app, we try to follow the recommendations set in
> > draft-
> > ietf-oauth-browser-based-apps-01. This doe
Hi Karl,
> On 7. May 2019, at 22:42, Karl McGuinness wrote:
>
> 1) You often need to deploy your cloud edge load balancer in TCP mode and
> handle your own TLS termination if you want client authentication.
I like that option since it gives end2end transport security for your
application. Un
16 matches
Mail list logo
