[Openid-specs-ab] client_credentials grant_type

John Bradley 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.

John B.
 
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"?
> 
> Sal
> 
> -----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
> Connect.
> 
> 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 mailing list