az acr create lists service principal actions with inconsistent parameter names

[sajayantony]

az acr create -l -n -g

returns
az ad sp create-for-rbac --scopes /subscriptions//resourcegroups//providers/Microsoft.ContainerRegistry/registries/ --role Owner --secret
az role assignment create --scope /subscriptions//resourcegroups//providers/Microsoft.ContainerRegistry/registries/ --role Owner --assignee

However, calling
az ad sp create-for-rbac --scopes /subscriptions//resourcegroups//providers/Microsoft.ContainerRegistry/registries/ --role Owner --secret bikeshare
Returns:
Client_id                             Sp_name                               Client_secret    Tenant
------------------------------------  ------------------------------------  ---------------  ------------------------------------
  http://  bikeshare        

Our helper text says app-d, however az ad sp create returns Client_Id, sp_name, Client_secret, ...

I then tried az ad sp list - which never returned #1150
Possibly provide help for calling az ad sp show --id

/cc @djyou

[djyou]

@yugangw-msft As specified in Graph API's spec, AppId should be the right name (or Application ID as used in the portal) rather than Client id. Key is the right name rather than Client secret. It has been rather confusing to the users. I would prefer if the output can retain the original property names returned by the server rather than rename them to the ones people may not be familiar with.

{
  "appId": "",
  "displayName": "",
  "objectId": ",
  "objectType": "ServicePrincipal",
  "servicePrincipalNames": [
    "",
    ""
  ]
}

[yugangw-msft]

Portal uses Client Id

[djyou]

[djyou]

Or APP ID in properties blade.

[djyou]

So is the spec
https://github.com/Azure/azure-rest-api-specs/blob/master/arm-graphrbac/1.6/swagger/graphrbac.json#L2153

[yugangw-msft]

Could you share out the steps of how to get to you snapshot? I was talking about the classic portal which lots of walkthroughes, say this one, uses to show people how to create service principal to login.
The create-for-rbac created the SP for people for login through the client id and secret flow. So using the client id and secret wording is more closely connected to the next step. Remember these 2 words are commonly used in oauth flow which the login goes through. Check out the API for reference
So azure-cli doesn't cause the confusions from the start , rather it picks the less worse.
Of course, I can consider to changing, but the justification should be scenario driven, rather from the graph apis, which existed decades ago and originally was from ADFS, not for RBAC

[djyou]

I was looking at the new portal Azure Active Directory extension. The inconsistency is from the fact that the result of az ad sp show --id shows AppId while create-for-rbac shows Client_id. Either name would work for us, but after create-for-rbac, the user won't see Client_id again from az ad sp list or az ad sp show.

[yugangw-msft]

I can add a new field of appid in the output with same value with client_id. We probably can't just rename it. client_id is also a well known concept like i mentioned earlier

[sajayantony]

@yugangw-msft either way we just want to be consistent. I guess the fact that CLIENT_ID was not used in the new portal might indicate that it the new name. Either way given that our service is preview we can pick up what ever is you recommend provided it is consistency.

[yugangw-msft]

Let me just switch to appId then. I will take this bug.

[JasonRShaver]

merged