[Openid-specs-ab] client_credentials grant_type
ve7jtb at ve7jtb.com
Mon Sep 17 15:46:25 UTC 2012
I don't understand the question.
In the BAE2 case the authentication is typically PIV or PIV-I.
That triggers the RP to do a SAML attribute query using the FASC-N as the subject identifier.
There is a philosophical question about enabling the retrieval of attributes without explicit user involvement.
I think there are better models, however there are people who believe they need this.
Some probably do.
On 2012-09-17, at 11:29 AM, Salvatore D'Agostino <sal at idmachines.com> wrote:
> OAuth or Connect derived from PIV or PIV as a scope?
> Or is this scope from the "attribute exchange"?
> -----Original Message-----
> From: John Bradley [mailto:ve7jtb at ve7jtb.com]
> Sent: Sunday, September 16, 2012 11:01 PM
> To: openid-specs-ab at lists.openid.net Group
> Subject: [Openid-specs-ab] client_credentials grant_type
> Last week I had several conversations with FICAM people around OAuth and
> One thing that they do and is also not uncommon in enterprises is permission
> access based on client credentials.
> Think SAML Attribute query.
> We do have that in OAuth 2.0.
> One thing we don't say in Connect is how to support that grant_type.
> It seems fairly strait forward that you would have a scope of openid and any
> other user_info related scopes, that nonce and state are not required.
> Returning a id_token probably doesn't make sense.
> To specify the user who is the subject we already have a way of passing the
> required user_id in the request object.
> I can see this being useful to compliment or replace a SAML/SOAP flow.
> We don't specifically talk about this or the Resource owner Password
> credentials Grant.
> As long as we don't do something in the core specs to preclude them we could
> put them in a separate profile as they are sort of special case.
> John B.
More information about the Openid-specs-ab