search

Azure-Samples / active-directory-verifiable-credentials

A code sample demonstrating how to use Azure Active Directory's preview functionality to issue and consume verifiable credentials.
107 stars 64 forks source link

Question: where can I find more information on what and how APIs are used in the Verifiable Credentials sample? #34

Closed jasoncys closed 3 years ago

jasoncys commented 3 years ago

Hi,

I'm curious to know what and how the APIs and communications between apps are being invoked in the sample app. I suppose the following sequence of calls between apps are being taken place for issuing VC:

  1. Click Get Credential button -> QR Code is generated -> "issue-request" (in app.js) is invoked.
  2. Scan QR Code in Microsoft Authenticator -> Authenticator "GET" "issue-request.jwt" in "app.js"
  3. Authenticator access the Verifiable Credentials "rules" and "display" -> Prompt for "Sign-in" according to the "attestations.idTokens.configuration" specified in the rules file.
  4. Sign in -> return "SUCCESS" or "FAILURE" to Microsoft Authenticator per the authentication service specified in "configuration". (Is it done through OAuth 2.0?)
  5. Display the "Add" button in Microsoft Authenticator if "SUCCESS".
  6. Click "Add" -> Verifiable Credential added to the Wallet.

Here are my questions:

  1. What type of service is required for Sign In by Microsoft Authenticator for issuing with Verifiable Credential? Any OAuth 2.0?
  2. Is there a DID generated by AD Verifiable Credentials and written to ION for the requester? If so, when and how is the DID of the requester being written to the ION network?
  3. When and how the Verifiable Credential of the requester is being generated and written to the ION network?
  4. Will a new Verifiable Credential generated for each request from the same requester? I suppose not. If not, how the previously generated VC is retrieved and passed to Authenticator? If yes, why?

Could you please help?

Cheers, Jason

johncra commented 3 years ago

Hi Jason,

Please take a look at my blog here: https://www.xtseminars.co.uk/post/issuing-dids-and-vcs-with-the-microsoft-example-app-and-authenticator

I think that should answer your questions. If not, let me know! Regards John

From: jasoncys @.> Sent: 21 May 2021 08:55 To: Azure-Samples/active-directory-verifiable-credentials @.> Cc: Subscribed @.***> Subject: [Azure-Samples/active-directory-verifiable-credentials] Question: where can I find more information on what and how APIs are used in the Verifiable Credentials sample? (#34)

Hi,

I'm curious to know what and how the APIs and communications between apps are being invoked in the sample app. I suppose the following sequence of calls between apps are being taken place for issuing VC:

  1. Click Get Credential button -> QR Code is generated -> "issue-request" (in app.js) is invoked.
  2. Scan QR Code in Microsoft Authenticator -> Authenticator "GET" "issue-request.jwt" in "app.js"
  3. Authenticator access the Verifiable Credentials "rules" and "display" -> Prompt for "Sign-in" according to the "attestations.idTokens.configuration" specified in the rules file.
  4. Sign in -> return "SUCCESS" or "FAILURE" to Microsoft Authenticator per the authentication service specified in "configuration". (Is it done through OAuth 2.0?)
  5. Display the "Add" button in Microsoft Authenticator if "SUCCESS".
  6. Click "Add" -> Verifiable Credential added to the Wallet.

Here are my questions:

  1. What type of service is required for Sign In by Microsoft Authenticator for issuing with Verifiable Credential? Any OAuth 2.0?
  2. Is there a DID generated by AD Verifiable Credentials and written to ION for the requester? If so, when and how is the DID of the requester being written to the ION network?
  3. When and how the Verifiable Credential of the requester is being generated and written to the ION network?
  4. Will a new Verifiable Credential generated for each request from the same requester? I suppose not. If not, how the previously generated VC is retrieved and passed to Authenticator? If yes, why?

Could you please help?

Cheers, Jason

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/Azure-Samples/active-directory-verifiable-credentials/issues/34, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGFPTB4OFVG6NGTMH4DRWR3TOYGWTANCNFSM45IUEIOQ.

jasoncys commented 3 years ago

Hi Jason, Please take a look at my blog here: https://www.xtseminars.co.uk/post/issuing-dids-and-vcs-with-the-microsoft-example-app-and-authenticator I think that should answer your questions. If not, let me know! Regards John From: jasoncys @.> Sent: 21 May 2021 08:55 To: Azure-Samples/active-directory-verifiable-credentials @.> Cc: Subscribed @.***> Subject: [Azure-Samples/active-directory-verifiable-credentials] Question: where can I find more information on what and how APIs are used in the Verifiable Credentials sample? (#34) Hi, I'm curious to know what and how the APIs and communications between apps are being invoked in the sample app. I suppose the following sequence of calls between apps are being taken place for issuing VC: 1. Click Get Credential button -> QR Code is generated -> "issue-request" (in app.js) is invoked. 2. Scan QR Code in Microsoft Authenticator -> Authenticator "GET" "issue-request.jwt" in "app.js" 3. Authenticator access the Verifiable Credentials "rules" and "display" -> Prompt for "Sign-in" according to the "attestations.idTokens.configuration" specified in the rules file. 4. Sign in -> return "SUCCESS" or "FAILURE" to Microsoft Authenticator per the authentication service specified in "configuration". (Is it done through OAuth 2.0?) 5. Display the "Add" button in Microsoft Authenticator if "SUCCESS". 6. Click "Add" -> Verifiable Credential added to the Wallet. Here are my questions: 1. What type of service is required for Sign In by Microsoft Authenticator for issuing with Verifiable Credential? Any OAuth 2.0? 2. Is there a DID generated by AD Verifiable Credentials and written to ION for the requester? If so, when and how is the DID of the requester being written to the ION network? 3. When and how the Verifiable Credential of the requester is being generated and written to the ION network? 4. Will a new Verifiable Credential generated for each request from the same requester? I suppose not. If not, how the previously generated VC is retrieved and passed to Authenticator? If yes, why? Could you please help? Cheers, Jason — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#34>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGFPTB4OFVG6NGTMH4DRWR3TOYGWTANCNFSM45IUEIOQ.

Thanks, John. The blog is very good and has answered most of my questions. I guess Q.4 remains open. :)

johncra commented 3 years ago

Hi Jason,

Re Q4. I am not completely clear what you mean by the requestor. There are three players the issuer (Azure AD), holder (The Authenticator) and the Verifier. In the Microsoft example, the issuer app triggers the request for a particular VC. The Azure AD VC service issues the VC, which is then held by the Authenticator. As part of the issuance, cycle the Authenticator gathers the claim values. One of the methods is to sign a user in using OpenID Connect and obtain an ID_token. The Authenticator then generates a subject DID (currently not published) and sends the ID_Token together with the subject DID to the VC service. The VC service, verifies the ID_Token, extracts the claims and then creates and signs a VC for the subject. That VC is stored in the Authenticator.

The Verifier makes a presentation request (defining the VCs that it wants presented). If this is seen as a new relying party, the Authenticator will generate a new subject DID and ask the VC service to swap the subject DID in the VC which is to be presented. If you want to see all of this, set up Fiddler to do remote capturing and proxy the Authenticator through Fiddler.

I hope that helps! John

From: jasoncys @.> Sent: 23 May 2021 03:02 To: Azure-Samples/active-directory-verifiable-credentials @.> Cc: John Craddock (XTSeminars) @.>; Comment @.> Subject: Re: [Azure-Samples/active-directory-verifiable-credentials] Question: where can I find more information on what and how APIs are used in the Verifiable Credentials sample? (#34)

Hi Jason, Please take a look at my blog here: https://www.xtseminars.co.uk/post/issuing-dids-and-vcs-with-the-microsoft-example-app-and-authenticator I think that should answer your questions. If not, let me know! Regards John From: jasoncys @.> Sent: 21 May 2021 08:55 To: Azure-Samples/active-directory-verifiable-credentials @.> Cc: Subscribed @.***> Subject: [Azure-Samples/active-directory-verifiable-credentials] Question: where can I find more information on what and how APIs are used in the Verifiable Credentials sample? (#34https://github.com/Azure-Samples/active-directory-verifiable-credentials/issues/34) Hi, I'm curious to know what and how the APIs and communications between apps are being invoked in the sample app. I suppose the following sequence of calls between apps are being taken place for issuing VC: 1. Click Get Credential button -> QR Code is generated -> "issue-request" (in app.js) is invoked. 2. Scan QR Code in Microsoft Authenticator -> Authenticator "GET" "issue-request.jwt" in "app.js" 3. Authenticator access the Verifiable Credentials "rules" and "display" -> Prompt for "Sign-in" according to the "attestations.idTokens.configuration" specified in the rules file. 4. Sign in -> return "SUCCESS" or "FAILURE" to Microsoft Authenticator per the authentication service specified in "configuration". (Is it done through OAuth 2.0?) 5. Display the "Add" button in Microsoft Authenticator if "SUCCESS". 6. Click "Add" -> Verifiable Credential added to the Wallet. Here are my questions: 1. What type of service is required for Sign In by Microsoft Authenticator for issuing with Verifiable Credential? Any OAuth 2.0? 2. Is there a DID generated by AD Verifiable Credentials and written to ION for the requester? If so, when and how is the DID of the requester being written to the ION network? 3. When and how the Verifiable Credential of the requester is being generated and written to the ION network? 4. Will a new Verifiable Credential generated for each request from the same requester? I suppose not. If not, how the previously generated VC is retrieved and passed to Authenticator? If yes, why? Could you please help? Cheers, Jason — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#34https://github.com/Azure-Samples/active-directory-verifiable-credentials/issues/34>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGFPTB4OFVG6NGTMH4DRWR3TOYGWTANCNFSM45IUEIOQ.

Thanks, John. The blog is very good and has answered most of my questions. I guess Q.4 remains open. :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/Azure-Samples/active-directory-verifiable-credentials/issues/34#issuecomment-846489052, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGFPTB4XOKP5PHCIBLWBOPTTPBOYDANCNFSM45IUEIOQ.

jasoncys commented 3 years ago

Thanks, John.

My question might be rephrased as: what information would AD VC Services write to the ION network in addition to the DID of the Issuer?

My understanding is that the AD VC Services would write the DID of the Holder as well as the Verifiable Credential to the ION Network in addition to the DID of the Issuer. (Is Fiddler able to trace such connections?) How would the Verifier trust the credential presented by the Holder if the Holder's DID cannot be found on the ION network? And how does the Verifier know if the credential presented by the Holder was actually issued by the Issuer if such a credential has no reference in the ION Network?

Referring to the pricing of the AD VC Services, it says the cost is $0.05 / 10,000 VC issued. So I suspect the AD VC Services would write the credential information to the ION network upon issuance.

My understanding might be wrong and I'd like to find out more technical information on how the AD VC Services actually work.

Thanks for the help. :)

Cheers, Jason

Hi Jason, Re Q4. I am not completely clear what you mean by the requestor. There are three players the issuer (Azure AD), holder (The Authenticator) and the Verifier. In the Microsoft example, the issuer app triggers the request for a particular VC. The Azure AD VC service issues the VC, which is then held by the Authenticator. As part of the issuance, cycle the Authenticator gathers the claim values. One of the methods is to sign a user in using OpenID Connect and obtain an ID_token. The Authenticator then generates a subject DID (currently not published) and sends the ID_Token together with the subject DID to the VC service. The VC service, verifies the ID_Token, extracts the claims and then creates and signs a VC for the subject. That VC is stored in the Authenticator. The Verifier makes a presentation request (defining the VCs that it wants presented). If this is seen as a new relying party, the Authenticator will generate a new subject DID and ask the VC service to swap the subject DID in the VC which is to be presented. If you want to see all of this, set up Fiddler to do remote capturing and proxy the Authenticator through Fiddler. I hope that helps! John From: jasoncys @.> Sent: 23 May 2021 03:02 To: Azure-Samples/active-directory-verifiable-credentials @.> Cc: John Craddock (XTSeminars) @.>; Comment @.> Subject: Re: [Azure-Samples/active-directory-verifiable-credentials] Question: where can I find more information on what and how APIs are used in the Verifiable Credentials sample? (#34) Hi Jason, Please take a look at my blog here: https://www.xtseminars.co.uk/post/issuing-dids-and-vcs-with-the-microsoft-example-app-and-authenticator I think that should answer your questions. If not, let me know! Regards John From: jasoncys @.> Sent: 21 May 2021 08:55 To: Azure-Samples/active-directory-verifiable-credentials @.> Cc: Subscribed @.***> Subject: [Azure-Samples/active-directory-verifiable-credentials] Question: where can I find more information on what and how APIs are used in the Verifiable Credentials sample? (#34<#34>) Hi, I'm curious to know what and how the APIs and communications between apps are being invoked in the sample app. I suppose the following sequence of calls between apps are being taken place for issuing VC: 1. Click Get Credential button -> QR Code is generated -> "issue-request" (in app.js) is invoked. 2. Scan QR Code in Microsoft Authenticator -> Authenticator "GET" "issue-request.jwt" in "app.js" 3. Authenticator access the Verifiable Credentials "rules" and "display" -> Prompt for "Sign-in" according to the "attestations.idTokens.configuration" specified in the rules file. 4. Sign in -> return "SUCCESS" or "FAILURE" to Microsoft Authenticator per the authentication service specified in "configuration". (Is it done through OAuth 2.0?) 5. Display the "Add" button in Microsoft Authenticator if "SUCCESS". 6. Click "Add" -> Verifiable Credential added to the Wallet. Here are my questions: 1. What type of service is required for Sign In by Microsoft Authenticator for issuing with Verifiable Credential? Any OAuth 2.0? 2. Is there a DID generated by AD Verifiable Credentials and written to ION for the requester? If so, when and how is the DID of the requester being written to the ION network? 3. When and how the Verifiable Credential of the requester is being generated and written to the ION network? 4. Will a new Verifiable Credential generated for each request from the same requester? I suppose not. If not, how the previously generated VC is retrieved and passed to Authenticator? If yes, why? Could you please help? Cheers, Jason — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#34<#34>>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGFPTB4OFVG6NGTMH4DRWR3TOYGWTANCNFSM45IUEIOQ. Thanks, John. The blog is very good and has answered most of my questions. I guess Q.4 remains open. :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#34 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGFPTB4XOKP5PHCIBLWBOPTTPBOYDANCNFSM45IUEIOQ.

johncra commented 3 years ago

In the current scenarios the holder is effectively the user (subject). When the VC service issues the DID it wraps the Subject DID and credentials in a message signed by the Issuer. It does not write the subject DID to ION. The issuer’s DID is written to ION. The VC is not written to ION.

It is likely that the subject wants to use a private (longform DID) and use a different private DID with each relying-party. In the future it may be possible to choose if the subject DID should be written to ION. There will be situations where the user wants a public DID.

The trust is as follows: The subject generates a private DID, the private key never leaves the subject’s possession. The subject requests a VC from the issuer service. The issuer service requires the subject to prove who they are, the level of identity proofing will vary from issuer to issuer. In the example app the subject is required to sign in to a B2C directory and that is the proof who they are. The VC service takes the subject DID and credentials and wraps them in a message signed by the VC service.

The user presents the VC wrapped and signed with their own private DID. The verifier now know that the message has come from the user (only the user has the private key). The verifier now checks the VC signed by the Issuer. The verifier trusts the issuer, because of DNS binding and proof of the Public DID published on ION. Inside the VC is the subject DID, if that matches the one presented by the user, the VC credentials are about the user and verified by the issuer.

There is no need to know anything about the user except what is presented in the VC.

From: jasoncys @.> Sent: 24 May 2021 09:23 To: Azure-Samples/active-directory-verifiable-credentials @.> Cc: John Craddock (XTSeminars) @.>; Comment @.> Subject: Re: [Azure-Samples/active-directory-verifiable-credentials] Question: where can I find more information on what and how APIs are used in the Verifiable Credentials sample? (#34)

Thanks, John.

My question might be rephrased as: what information would AD VC Services write to the ION network in addition to the DID of the Issuer?

My understanding is that the AD VC Services would write the DID of the Holder as well as the Verifiable Credential to the ION Network in addition to the DID of the Issuer. (Is Fiddler able to trace such connections?) How would the Verifier trust the credential presented by the Holder if the Holder's DID cannot be found on the ION network? And how does the Verifier know if the credential presented by the Holder was actually issued by the Issuer if such a credential has no reference in the ION Network?

Referring to the pricing of the AD VC Services, it says the cost is $0.05 / 10,000 VC issued. So I suspect the AD VC Services would write the credential information to the ION network upon issuance.

My understanding might be wrong and I'd like to find out more technical information on how the AD VC Services actually work.

Thanks for the help. :)

Cheers, Jason

Hi Jason, Re Q4. I am not completely clear what you mean by the requestor. There are three players the issuer (Azure AD), holder (The Authenticator) and the Verifier. In the Microsoft example, the issuer app triggers the request for a particular VC. The Azure AD VC service issues the VC, which is then held by the Authenticator. As part of the issuance, cycle the Authenticator gathers the claim values. One of the methods is to sign a user in using OpenID Connect and obtain an ID_token. The Authenticator then generates a subject DID (currently not published) and sends the ID_Token together with the subject DID to the VC service. The VC service, verifies the ID_Token, extracts the claims and then creates and signs a VC for the subject. That VC is stored in the Authenticator. The Verifier makes a presentation request (defining the VCs that it wants presented). If this is seen as a new relying party, the Authenticator will generate a new subject DID and ask the VC service to swap the subject DID in the VC which is to be presented. If you want to see all of this, set up Fiddler to do remote capturing and proxy the Authenticator through Fiddler. I hope that helps! John From: jasoncys @.> Sent: 23 May 2021 03:02 To: Azure-Samples/active-directory-verifiable-credentials @.> Cc: John Craddock (XTSeminars) @.>; Comment @.> Subject: Re: [Azure-Samples/active-directory-verifiable-credentials] Question: where can I find more information on what and how APIs are used in the Verifiable Credentials sample? (#34https://github.com/Azure-Samples/active-directory-verifiable-credentials/issues/34) Hi Jason, Please take a look at my blog here: https://www.xtseminars.co.uk/post/issuing-dids-and-vcs-with-the-microsoft-example-app-and-authenticator I think that should answer your questions. If not, let me know! Regards John From: jasoncys @.> Sent: 21 May 2021 08:55 To: Azure-Samples/active-directory-verifiable-credentials @.> Cc: Subscribed @.***> Subject: [Azure-Samples/active-directory-verifiable-credentials] Question: where can I find more information on what and how APIs are used in the Verifiable Credentials sample? (#34https://github.com/Azure-Samples/active-directory-verifiable-credentials/issues/34<#34https://github.com/Azure-Samples/active-directory-verifiable-credentials/issues/34>) Hi, I'm curious to know what and how the APIs and communications between apps are being invoked in the sample app. I suppose the following sequence of calls between apps are being taken place for issuing VC: 1. Click Get Credential button -> QR Code is generated -> "issue-request" (in app.js) is invoked. 2. Scan QR Code in Microsoft Authenticator -> Authenticator "GET" "issue-request.jwt" in "app.js" 3. Authenticator access the Verifiable Credentials "rules" and "display" -> Prompt for "Sign-in" according to the "attestations.idTokens.configuration" specified in the rules file. 4. Sign in -> return "SUCCESS" or "FAILURE" to Microsoft Authenticator per the authentication service specified in "configuration". (Is it done through OAuth 2.0?) 5. Display the "Add" button in Microsoft Authenticator if "SUCCESS". 6. Click "Add" -> Verifiable Credential added to the Wallet. Here are my questions: 1. What type of service is required for Sign In by Microsoft Authenticator for issuing with Verifiable Credential? Any OAuth 2.0? 2. Is there a DID generated by AD Verifiable Credentials and written to ION for the requester? If so, when and how is the DID of the requester being written to the ION network? 3. When and how the Verifiable Credential of the requester is being generated and written to the ION network? 4. Will a new Verifiable Credential generated for each request from the same requester? I suppose not. If not, how the previously generated VC is retrieved and passed to Authenticator? If yes, why? Could you please help? Cheers, Jason — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#34https://github.com/Azure-Samples/active-directory-verifiable-credentials/issues/34<#34https://github.com/Azure-Samples/active-directory-verifiable-credentials/issues/34>>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGFPTB4OFVG6NGTMH4DRWR3TOYGWTANCNFSM45IUEIOQ. Thanks, John. The blog is very good and has answered most of my questions. I guess Q.4 remains open. :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#34 (comment)https://github.com/Azure-Samples/active-directory-verifiable-credentials/issues/34#issuecomment-846489052>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGFPTB4XOKP5PHCIBLWBOPTTPBOYDANCNFSM45IUEIOQ.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/Azure-Samples/active-directory-verifiable-credentials/issues/34#issuecomment-846871947, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGFPTB6MBQ44Y3MLOQA7WDDTPIEHDANCNFSM45IUEIOQ.

jasoncys commented 3 years ago

Thanks, John. It clarifies. Cheers, Jason